On 1/25/2013 8:43 PM, Stas Malyshev wrote:
Hi!
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?
People think that "introduce a configuration parameter" is a solution to
almost any BC problem in the engine. It's not true, actually it's the
opposite - now you have to maintain two code bases, one for one value of
the parameter and one for another. Now imagine there's 10 such
parameters, for different things in PHP, and you get 1024 options to
test you application on. That's why we try to reduce behavior-modifying
options to a minimum. Config options are for configuration, not for
changing engine behavior in BC-breaking way. That's one of the reasons
why magic_* were not a good idea and we had to get rid of them.
And imagine integrating a library that is written with one set of engine
options into application that expects another set of options. Now
imagine application that uses a dozen of third-party libraries (in
current open-source world, it's not too many at all), each of them
expecting its own set of engine-modifying options. It would very quickly
become a complete nightmare.
So I think we should try to keep PHP behavior unified and avoid
behavior-modifying switches as much as possible.
I agree all of that would suck, but would it suck less than the
alternatives for the most people involved?
--
-Clint
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
