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