Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91384
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.45 as permitted sender)
To: internals@lists.php.net
References: <CAF+90c_1zO91x-4Madqm3F8gkKDT7jZKVZSbBuYMbnDCADrv_A@mail.gmail.com>
 <56C63A8A.3030809@gmail.com> <97CC6432-564B-4E28-B2DE-9C496FF1984D@zend.com>
Message-ID: <56CE3A6E.2070205@gmail.com>
Date: Wed, 24 Feb 2016 23:19:10 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <97CC6432-564B-4E28-B2DE-9C496FF1984D@zend.com>
Content-Type: text/plain; charset=windows-1255; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 7.1
From: rowan.collins@gmail.com (Rowan Collins)

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]