Re: Proposal to deprecate create_function()

On Fri, Oct 18, 2013 at 2:19 PM, Nikita Popov <nikita.ppv@gmail.com> wrote: > On Fri, Oct 18, 2013 at 12:39 PM, Crypto Compress < > cryptocompress@googlemail.com> 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