On 03/03/15 18:54, Yasuo Ohgaki wrote: > More or less, we do need maintenance, otherwise phpversion() will remain > inconsistent forever. IMO.
Is there any reason why a few peripheral functions like that can't simply remain as is? ADDING an object with what I will simply describe as 'the new style of coding' which provides an alternative API has to be the sensible way forward. An object for ini management with a more convenient display function in addition to the simple phpversion dump. > I fully understand your arguments/reasoning, but I fails to see why not > having aliases to have shiny procedural APIs for major version up... Changing the parameter order on the existing function set is not practical, but similarly so is changing names which will then produce an abysmal mess when searching help files especially when reliance on google to provide that function means that we have no control on just which version of names are looked up. The more I look at this from the other side, the better the idea of simply adding new format objects to augment the legacy function set looks. Certainly leaving things like gd alone and adding a parallel 'coding style complainant' extension also allows changes to the parameter order. Apply the same approach to some of the other extensions and at some point in the future we can drop legacy versions ... although I suspect that a legacy build will still have a place for some time to come. The piece of the jigsaw I am missing is at which point does it become better to create a new extension for a complex object rather than simply writing a set of PHP classes? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
