Re: I think that "Function naming inconsistency" bug deservers more attention

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