On Fri, Oct 18, 2013 at 2:19 PM, Nikita Popov <[email protected]> wrote:
> On Fri, Oct 18, 2013 at 12:39 PM, Crypto Compress <
> [email protected]> wrote:
>
> > Hello,
> >
> > shure all things can be replaced with more and verbose code. What is the
> > benefit of writing all this lines in contrast to one method call?
> > https://github.com/phpcr/**phpcr-utils/blob/master/src/**
> > PHPCR/Util/Console/Helper/**PhpcrCliHelper.php#L111<
> https://github.com/phpcr/phpcr-utils/blob/master/src/PHPCR/Util/Console/Helper/PhpcrCliHelper.php#L111
> >
> >
> > -1 for removing wrappers/abbreviations/and such
> > +1 for bugfixing
> >
> > Best,
> > CC
> >
>
> Could you maybe elaborate a bit on your use case there? I.e. provide some
> context as to why the create_function call there is necessary and why it
> can't be replaced with use of anonymous functions (and maybe also what
> additional constraints there are). For people like myself that are not
> familiar with the exact workings of that library.
>
> Thanks,
> Nikita
>
I guess he is trying to say that writing a factory method for producing
callable/anonymous functions are easier with create_function than with
closures, because you call eval implicitly, instead of explicitly.
I've only skimmed through the thread, but did somebody already proposed
changing the return value of create_function to return a closure instead of
deprecating it?
That way we could keep bc and remove the ugly null-prefixed hidden function
from the global function table.
If we really we want 100% compatibility, we could even add a __toString to
the Closure object with an internal function name (similar was proposed by
Joe for anonymous functions and I listed it as a con, because not matching
the current behaviors of Closures) through which it can be called as a
string while throwing a STRICT/DEPRECATED error so people can move away
from manipulating the return value as a string, and we can remove that
behavior later on.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu