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
