Hello everyone, Might I suggest community feedback on this one in a reddit thread? My guess is that even though a lot of applications out there are still PHP 4 ctor reliant, a very low percentage of these applications might be under active development.
Best, Stelian On Fri, Jan 16, 2015 at 12:28 PM, Derick Rethans <der...@php.net> wrote: > On Thu, 15 Jan 2015, Levi Morrison wrote: > > > On Thu, Jan 15, 2015 at 9:55 AM, Andrea Faulds <a...@ajf.me> wrote: > > > > > > Upon further thought, I’m not super-enthusiastic about this. As has > > > been pointed out, it’s a pretty serious BC break, whether code can > > > be automatically updated or not. PHP 4 constructors may be obsolete, > > > but an awful lot of code uses them. > > > > > > A better solution, IMO, might be simply to add a deprecation notice. > > > This would make it obvious during development if you’ve accidentally > > > defined a PHP4 constructor, and would encourage migration away from > > > them, but wouldn’t prevent existing code from working. > > > > Possibly. The reality of my position is that I am unhappy about our > > current constructor situation. Having `__construct` and only > > half-heartedly supporting old-style constructors for the next several > > years (maybe ten?) does not sound good at all. > > > > Removing one of the constructors is a nicer end product than fully > > supporting both, in my opinion, which is why I proposed dropping it. > > Instead of just dropping it, which would likely generate odd bugs, > declaring an old style constructor should *tell* you it's no longer > working- perhaps with as strong of an error as an > E_COMPILE_ERROR—atleast for PHP 7. Just removing it support would, IMO, > be silly. > > cheers, > Derick > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
