Re: [RFC] Default constructors
| From: | Rowan Collins | Date: | Wed, 19 Nov 2014 09:21:31 +0000 |
| Subject: | Re: [RFC] Default constructors | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-78986@lists.php.net to get a copy of this message | ||
On 19 November 2014 01:50:33 GMT, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>> Yes, that's a bug :-)
>
>No, it is not :)
>We can do it all day but I think I've explained what is going on there.
>If you want to change it, feel free to do the RFC.
The point of this discussion is that there is an RFC on the table which can be implemented in such a
way that it fixes this behaviour (by introducing a default parent, or injecting an empty
constructor) or such that it carefully preserves it (by making a special case for
parent::__construct).
If you are, as you seem to be, defending this as a feature, it implies we should preserve (and,
incidentally, standardise) it. If, as I and others argue, it was only ever an unintended effect of
the implementation, then we should take the opportunity to correct it.
This reminds me of the recent discussion over multiple defaults in a switch. Perhaps as with that we
should phrase the question as "is there any useful purpose to having the language standardised
with this feature, and conversely is there any realistic harm in altering it?"