On 1/17/2017 10:11 PM, Tim Bezhashvyly wrote: > Hi Marcio, > > there is no deprecation because nothing is deprecated. This is a > behavioural constrain. > > Regarding parent() this is just one possible future RFC. Our > intention was just to depict that the RFC in hand opens such > possibilities. There is no obligation. > > Regards, Tim > >> On 17 Jan 2017, at 22:08, Marcio Almada <marcio.w...@gmail.com> >> wrote: >> >> Hi Tim, >> >> I'm ok with the idea. But could you elaborate why not propose a >> deprecation before the error on PHP 8? >> >> Also, one point about the future scope "Add shorthand parent() as >> alternative to parent::__construct().": Do we really need to >> introduce more language constructs that look like valid user space >> code https://3v4l.org/CE2q8 <https://3v4l.org/CE2q8> ? >> >> Thanks. Márcio. >> >
Actually expanding on how to handle the upgrade path in case the decision falls on PHP 8 makes perfect sense. Emitting an error with deprecation severity too. Hence: https://wiki.php.net/rfc/disallow-multiple-constructor-calls#upgrade_paths Many thanks for the input! Regarding your other point. We just listed all constructor related ideas from the initial thread but we might not even be involved in their writing or they might never be created. Let's stick to the discussed RFC only here, thanks. -- Richard "Fleshgrinder" Fussenegger -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
