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. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
