On 18/02/2016 22:45, Zeev Suraski wrote:
>> I'm not sure about create_function() - while it is old, I don't see why
>> we should break working code using it just because better option is
>> available.
> There's that, and there's the fact closures don't give you the same
functionality - as Andrea pointed out. I think
> deprecating it and forcing people to rewrite their code differently
(either with eval or with closures) doesn't make
> a whole lot of sense when create_function() works perfectly well. In
terms of security risks, if you use it like you
> use closures I don't think it's any riskier. If you need eval() for
programmatically creating functions - it would obviously
> be at the exact same risk levels. So we're left with marginal
performance gains - as practically speaking you don't
> typically create thousands of functions dynamically in a given
request. If you do, chances are you've already
> migrated to closures.
Funnily enough, one of my first contributions to this list was to
propose deprecating create_function:
http://marc.info/?l=php-internals&m=138178645724006&w=2
The answers to my proposal were mixed, as they have been here: some
agreed that it was ugly and a potential security problem if misused;
some pointed out use cases which can't trivially be implemented with
Closures, such as this:
https://github.com/phpcr/phpcr-utils/blob/42db960a6c58dcc3a71c2e4770050cda36f17c5b/src/PHPCR/Util/Console/Command/NodesUpdateCommand.php#L68
In the end I dropped the idea on the grounds that a deprecation notice
should have a clear migration path for all reasonable use cases, not
just some of them.
I tend to agree with Stas that deprecations need to be justified more
strongly than a general desire for tidiness. As with "can we rename
functions / fix argument order / etc", I wonder if there's scope for
publishing an FAQ which, while not holding the force of Official Policy,
is nonetheless endorsed as consensus to guide new contributions...
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
