On 1/25/2013 7:02 PM, Stas Malyshev wrote:
Hi!
Well, how about renaming the functions, create aliases for BC and throw
E_DEPRECATED or E_STRICT on their usage? And write a PEAR script bundled
with the distribution to migrate to the new convention?
Well, the problem with these things is this: suppose you have testing
suite that verifies your code. What you do with E_DEPRECATED? You can
treat them as failure, and that means in hypothetical PHP 6 release you
code is broken, and you can't release it until you fixed it - so that
means for you the effect it as if the function was effectively removed.
On the other hand, you can ignore it - and then when these functions are
removed, you get all your code broken, and while it is not removed, it's
like we didn't do anything.
Depending on just what is going to change, a simple script people can
run to scan their code and spit out a diff of recommended changes they
can simply review and approve of could be pretty painless.
Then again you probably have people that would be subject to vendor
updates without the ability to run the script or understand the changes
it recommends. May be a small minority though.
Are we talking mostly needle/haystack & haystack/needle type BC changes
here or other more nefarious things?
Realistically couldn't we just introduce a configuration parameter to
keep "the inconsistent parameter order," perhaps along with a script to
suggest the changes needed to bring some code up to speed?
Would be a bit more in the core, for a time, but would allow people to
transition when they wanted to, without all of the errors...
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
