Dear internals,
me and Richard Fussenegger came up with a RFC draft disallowing multiple constructor calls - https://wiki.php.net/rfc/disallow-multiple-constructor-calls https://wiki.php.net/rfc/disallow-multiple-constructor-calls
Here is a Reddit discussion thread - https://www.reddit.com/r/PHP/comments/5okdac/php_rfc_disallow_multiple_constructor_calls/ https://www.reddit.com/r/PHP/comments/5okdac/php_rfc_disallow_multiple_constructor_calls/
Any suggestions are highly welcome. Thank you.
Regards,
Tim
Hey Tim,
On Tue, Jan 17, 2017 at 9:17 PM, Tim Bezhashvyly tim.bezhashvyly@gmail.com
wrote:
Dear internals,
me and Richard Fussenegger came up with a RFC draft disallowing multiple
constructor calls - https://wiki.php.net/rfc/
disallow-multiple-constructor-calls <https://wiki.php.net/rfc/
disallow-multiple-constructor-calls>Here is a Reddit discussion thread - https://www.reddit.com/r/PHP/
comments/5okdac/php_rfc_disallow_multiple_constructor_calls/ <
https://www.reddit.com/r/PHP/comments/5okdac/php_rfc_
disallow_multiple_constructor_calls/>Any suggestions are highly welcome. Thank you.
Regards,
Tim
This looks much better than the initial proposal, thanks!
Marco Pivetta
On Tue, Jan 17, 2017 at 9:17 PM, Tim Bezhashvyly tim.bezhashvyly@gmail.com
wrote:
Dear internals,
me and Richard Fussenegger came up with a RFC draft disallowing multiple
constructor calls - https://wiki.php.net/rfc/
disallow-multiple-constructor-calls <https://wiki.php.net/rfc/
disallow-multiple-constructor-calls>Here is a Reddit discussion thread - https://www.reddit.com/r/PHP/
comments/5okdac/php_rfc_disallow_multiple_constructor_calls/ <
https://www.reddit.com/r/PHP/comments/5okdac/php_rfc_
disallow_multiple_constructor_calls/>Any suggestions are highly welcome. Thank you.
Regards,
Tim
Without putting a lot of though into this, the restriction sounds
reasonable.
However, it is not immediately clear to me how this can be implemented
without adding a disproportionate amount of overhead for something which I
would consider a rather minor feature. If an object only had a single
constructor this would be a simple flag, but if you want to allow one call
per each constructor in the hierarchy (i.e. you can call the constructor
and each parent constructor once), this information needs to be stored
somehow. The obvious way would be a hashset containing the constructors (or
CEs) that have been called on the object, but I don't think this would be
acceptable.
Regards,
Nikita
Hi Nikita,
thank you for your feedback. Would you suggest to convert RFC into prohibition of explicit __construct calls except parent::__construct?
Regards,
Tim
Dear internals,
me and Richard Fussenegger came up with a RFC draft disallowing multiple constructor calls - https://wiki.php.net/rfc/disallow-multiple-constructor-calls https://wiki.php.net/rfc/disallow-multiple-constructor-calls <https://wiki.php.net/rfc/disallow-multiple-constructor-calls https://wiki.php.net/rfc/disallow-multiple-constructor-calls>
Here is a Reddit discussion thread - https://www.reddit.com/r/PHP/comments/5okdac/php_rfc_disallow_multiple_constructor_calls/ https://www.reddit.com/r/PHP/comments/5okdac/php_rfc_disallow_multiple_constructor_calls/ <https://www.reddit.com/r/PHP/comments/5okdac/php_rfc_disallow_multiple_constructor_calls/ https://www.reddit.com/r/PHP/comments/5okdac/php_rfc_disallow_multiple_constructor_calls/>
Any suggestions are highly welcome. Thank you.
Regards,
TimWithout putting a lot of though into this, the restriction sounds reasonable.
However, it is not immediately clear to me how this can be implemented without adding a disproportionate amount of overhead for something which I would consider a rather minor feature. If an object only had a single constructor this would be a simple flag, but if you want to allow one call per each constructor in the hierarchy (i.e. you can call the constructor and each parent constructor once), this information needs to be stored somehow. The obvious way would be a hashset containing the constructors (or CEs) that have been called on the object, but I don't think this would be acceptable.
Regards,
Nikita
Without putting a lot of though into this, the restriction sounds
reasonable.However, it is not immediately clear to me how this can be implemented
without adding a disproportionate amount of overhead for something which I
would consider a rather minor feature. If an object only had a single
constructor this would be a simple flag, but if you want to allow one call
per each constructor in the hierarchy (i.e. you can call the constructor
and each parent constructor once), this information needs to be stored
somehow. The obvious way would be a hashset containing the constructors (or
CEs) that have been called on the object, but I don't think this would be
acceptable.Regards,
Nikita
Hey Nikic!
Thanks for skimming over it. I also though about implementation already.
My initial though was -- especially to keep it simple -- to simply
delete the method from the object's table.
Not sure if this is possible or just introduced more problems than it
solves. Also considering that we think reflection should continue to
allow calling it multiple times, though this is obviously still debatable.
--
Richard "Fleshgrinder" Fussenegger
Without putting a lot of though into this, the restriction sounds
reasonable.However, it is not immediately clear to me how this can be implemented
without adding a disproportionate amount of overhead for something which
I
would consider a rather minor feature. If an object only had a single
constructor this would be a simple flag, but if you want to allow one
call
per each constructor in the hierarchy (i.e. you can call the constructor
and each parent constructor once), this information needs to be stored
somehow. The obvious way would be a hashset containing the constructors
(or
CEs) that have been called on the object, but I don't think this would be
acceptable.Regards,
NikitaHey Nikic!
Thanks for skimming over it. I also though about implementation already.
My initial though was -- especially to keep it simple -- to simply
delete the method from the object's table.Not sure if this is possible or just introduced more problems than it
solves. Also considering that we think reflection should continue to
allow calling it multiple times, though this is obviously still debatable.
Methods are stored on the class, with the object containing a pointer to
the class. As such, it's not possible to delete a method from a single
object, you can only delete a method from the entire class. (In practice
you can't do that either ^^)
Nikita
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 ?
Thanks.
Márcio.
2017-01-17 16:17 GMT-04:00 Tim Bezhashvyly tim.bezhashvyly@gmail.com:
Dear internals,
me and Richard Fussenegger came up with a RFC draft disallowing multiple
constructor calls - https://wiki.php.net/rfc/
disallow-multiple-constructor-calls <https://wiki.php.net/rfc/
disallow-multiple-constructor-calls>Here is a Reddit discussion thread - https://www.reddit.com/r/PHP/
comments/5okdac/php_rfc_disallow_multiple_constructor_calls/ <
https://www.reddit.com/r/PHP/comments/5okdac/php_rfc_
disallow_multiple_constructor_calls/>Any suggestions are highly welcome. Thank you.
Regards,
Tim
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
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.2017-01-17 16:17 GMT-04:00 Tim Bezhashvyly <tim.bezhashvyly@gmail.com mailto:tim.bezhashvyly@gmail.com>:
Dear internals,me and Richard Fussenegger came up with a RFC draft disallowing multiple constructor calls - https://wiki.php.net/rfc/disallow-multiple-constructor-calls https://wiki.php.net/rfc/disallow-multiple-constructor-calls <https://wiki.php.net/rfc/disallow-multiple-constructor-calls https://wiki.php.net/rfc/disallow-multiple-constructor-calls>
Here is a Reddit discussion thread - https://www.reddit.com/r/PHP/comments/5okdac/php_rfc_disallow_multiple_constructor_calls/ https://www.reddit.com/r/PHP/comments/5okdac/php_rfc_disallow_multiple_constructor_calls/ <https://www.reddit.com/r/PHP/comments/5okdac/php_rfc_disallow_multiple_constructor_calls/ https://www.reddit.com/r/PHP/comments/5okdac/php_rfc_disallow_multiple_constructor_calls/>
Any suggestions are highly welcome. Thank you.
Regards,
Tim
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.web2@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