On Thu, Jan 15, 2015 at 9:55 AM, Andrea Faulds <a...@ajf.me> wrote: > Hey Levi, > > 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. I was hoping that a deprecation notice in 5.7 would be sufficient along with other standard migration tools and documentation, but since we have decided to not release 5.7 perhaps a deprecation would be better. At the same time I'm not thrilled about the amount of deprecation notices that could be generated if this is really as common as people seem to make it. I generally don't see these older constructors, but it seems when people have them they have *a lot* of them. I was okay with this in a theoretical 5.7 release to ease migration because it had a fixed lifespan of one release cycle but in version 7 it will stay for the duration of all PHP 7 releases. What do you guys think? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
