Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC][DISCUSSION] - Disallow Multiple Constructor Calls »

[RFC][DISCUSSION] - Disallow Multiple Constructor Calls

php.internals

Tim Bezhashvyly

9 years ago
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

Marco Pivetta

9 years ago
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 http://twitter.com/Ocramius http://ocramius.github.com/

Nikita Popov

9 years ago
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

Tim Bezhashvyly

9 years ago
Hi Nikita, thank you for your feedback. Would you suggest to convert RFC into prohibition of explicit __construct calls except parent::__construct? Regards, Tim

Fleshgrinder

9 years ago
On 1/17/2017 9:48 PM, Nikita Popov wrote:
> 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

Nikita Popov

9 years ago
On Tue, Jan 17, 2017 at 9:52 PM, Fleshgrinder <php@fleshgrinder.com> wrote:
> On 1/17/2017 9:48 PM, Nikita Popov wrote: > > 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. >
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

Marcio Almada

9 years ago
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>:

Tim Bezhashvyly

9 years ago
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

Fleshgrinder

9 years ago
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.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