Re: [RFC] Deprecations for PHP 7.1

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]