Rather than being a bug, this matter is simply a "gotcha", one that Julien
Pauli' pointed out in his "PHP gotcha 2013" (see
https://gist.github.com/jpauli/8196145). After consulting with other
knowledgeable members of the PHP Community last year, I understand that this
is an optimization feature such that the generated opcode doesn't get
executed when the constructor is non-existent. One might not like this
"gotcha", but does it really merit being "fixed"? As a user, I like this
feature since it seems sensible if one is concerned with efficient code
execution. Whereas the undefined __construct {} permits the opcode to
execute even tho' the resulting value is useless for the class. If
anything needs to change, possibly it's the latter situation.
In sum, +1 for the option "carefully preserves it (by making a special case
for parent::__construct)"
-- SLevy
----- Original Message -----
From: "Rowan Collins" <rowan.coll...@gmail.com>
To: "Stanislav Malyshev" <smalys...@gmail.com>; "Marco Pivetta"
<ocram...@gmail.com>
Cc: "PHP Internals List" <internals@lists.php.net>
Sent: Wednesday, November 19, 2014 1:21 AM
Subject: Re: [PHP-DEV] [RFC] Default constructors
On 19 November 2014 01:50:33 GMT, Stanislav Malyshev <smalys...@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?"
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
