On 20/11/14 21:29, Rowan Collins wrote: > The problem is that the constructor is part of the public API (for > inheritance purposes) so the required refactoring is not necessarily isolated > to one project, or even doable by one developer. The maintainer of the > library must first release a version with the new constructors in place, and > the consumer of the library must then audit their code for anything relying > on the old constructor. Supporting various combinations of PHP 5/7, old/new > lib, and old/new consumer code is then messy at best. > > I agree that it's perfectly doable, but it's not as easy to migrate as, say, > a syntax change.
I know I sound like a broken record, but this is EXACTLY the same problem as e_strict! It is all very well saying old code can still run if you hide the the warnings and ERRORS, but you have to spend the time fixing each and every warning simply to ensure that it will work on the next release ... hiding things does not work. And I still run my own version of PEAR to get around the e_strict problems! -- 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
