# [RFC][Draft] Body-less __construct - Thread: https://externals.io/message/114324 - Original archive: https://news-web.php.net/php.internals/114324 - Started by mrtreinis@gmail.com on 2021-05-10T08:29:21+00:00 - Messages: 34 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/114324.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #114324 — mrtreinis@gmail.com — 2021-05-10T08:29:21+00:00 URL: https://externals.io/message/114324#114324 Hi everyone, Since constructor property promotion is now implemented, and it looks like it could become a widely used feature, I am proposing a small, cosmetic change in syntax for constructors in concrete classes to do away with empty constructor body. Here's an example of how this would work: Hi everyone, > > Since constructor property promotion is now implemented, and it looks > like it could become a widely used feature, I am proposing a small, > cosmetic change in syntax for constructors in concrete classes to do > away with empty constructor body. > > Here's an example of how this would work: > > namespace App; > > class Foo { > public function __construct( > private Bar $bar, > private Baz $baz > ); > } > > Some notes to this: > > - Since this is similar to already existing syntax for body-less > methods, parser should not be affected that much. I hope. I really have > no idea. > - Syntax would be optional - meaning, you can as well continue using > empty body, just that in this case the body would be implied empty. > > Thoughts? > Regards, > - Matīss --- ## #114326 — mrtreinis@gmail.com — 2021-05-10T08:49:39+00:00 URL: https://externals.io/message/114324#114326 · In reply to: #114325 Hi Marco, I am not sure, that's why I am asking for feedback. I have been converting a ton of code to use constructor property promotion and the absolute majority ends up with the method body being empty. I reckon this could be a nice eye-candy to have, however, it's nothing more than that. Another point to be made here, as far as my interpretation of PSR-12, the curly braces occupy two lines for methods with multiline arguments. So for whoever follows PSR-12, it's more like this, with brackets just dangling there across 2 lines. [...] class Foo { public function __construct( private Bar $bar, private Baz $baz ) { } } - Matīss > Hey Matīss, > > This already works by replacing `;` with `{}`: https://3v4l.org/tN4HM > > Is the change in AST really necessary, considering that? > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/ > > > On Mon, May 10, 2021 at 10:29 AM Matīss Treinis > wrote: > > > […] --- ## #114327 — Ilija Tovilo — 2021-05-10T08:54:50+00:00 URL: https://externals.io/message/114324#114327 · In reply to: #114325 Hi internals > > Hey Matīss, > > This already works by replacing `;` with `{}`: https://3v4l.org/tN4HM > > Is the change in AST really necessary, considering that? The root problem is not that {} is significantly worse than ; but it's that some cs tools require obnoxious formatting. ``` class Foo { public function __construct( private Bar $bar, private Baz $baz ) { } } ``` I agree with Marco, it makes more sense to fix the cs guidelines rather than to adjust the language just to work around it. Ilija --- ## #114328 — Marco Pivetta — 2021-05-10T08:55:42+00:00 URL: https://externals.io/message/114324#114328 · In reply to: #114326 > Hi Marco, > > I am not sure, that's why I am asking for feedback. > > I have been converting a ton of code to use constructor property promotion > and the absolute majority ends up with the method body being empty. I > reckon this could be a nice eye-candy to have, however, it's nothing more > than that. > > Another point to be made here, as far as my interpretation of PSR-12, the > curly braces occupy two lines for methods with multiline arguments. So for > whoever follows PSR-12, it's more like this, with brackets just dangling > there across 2 lines. > > [...] > class Foo { > public function __construct( > private Bar $bar, > private Baz $baz > ) { > } > } > Given that: * `{}` can already represent what you want * the issue is more of a coding-style related topic I suggest bringing this up in a new PSR instead. Consider that PSR-1, PSR-2 and PSR-12 were designed pre-PHP-8, so they will need adjustments again, but AFAIK nothing has moved yet, since the ecosystem is still adapting to the PHP 8 changes (I myself haven't finished adopting it on many of my libraries). If this is relevant to you right now, add an exclusion to your `phpcs.xml.dist` instead: easier and less painful than expanding the language for such a tiny detail. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ --- ## #114329 — Aleksander Machniak — 2021-05-10T08:59:57+00:00 URL: https://externals.io/message/114324#114329 · In reply to: #114326 > Another point to be made here, as far as my interpretation of PSR-12, the > curly braces occupy two lines for methods with multiline arguments. So for > whoever follows PSR-12, it's more like this, with brackets just dangling > there across 2 lines. > > [...] > class Foo { > public function __construct( > private Bar $bar, > private Baz $baz > ) { > } > } or some would prefer: class Foo { public function __construct( private Bar $bar, private Baz $baz ) { // empty } } The question to the proposal. Will this new syntax apply to: 1. all methods 2. all constructors 3. only to constructors with property promotion? I think 3 makes most sense here and is less contentious. So, just be sure to specify this in the RFC. -- Aleksander Machniak Kolab Groupware Developer [https://kolab.org] Roundcube Webmail Developer [https://roundcube.net] ---------------------------------------------------- PGP: 19359DC1 # Blog: https://kolabian.wordpress.com --- ## #114331 — mrtreinis@gmail.com — 2021-05-10T09:12:05+00:00 URL: https://externals.io/message/114324#114331 · In reply to: #114328 I don't necessarily agree with this point in particular - I mentioned PSR just-by-driveby, since whoever does follow that convention will face this issue - but the scope of the proposal is not limited to PSR adopters. It's also worth pointing out that PSR is not an "official" coding guideline for PHP, and therefore we should probably not limit the scope to it, simply because regardless if the brackets are on the same line or not, they are still there. IMO, this is a language issue - topical, cosmetic, and minor - but language issue nevertheless, in fact, exactly like the one had for attribute syntax. Let's gather some feedback and see. - Matīss > > On Mon, May 10, 2021 at 10:50 AM Matīss Treinis > wrote: > > > […] > > Given that: > > * `{}` can already represent what you want > * the issue is more of a coding-style related topic > > I suggest bringing this up in a new PSR instead. Consider that PSR-1, > PSR-2 and PSR-12 were designed pre-PHP-8, so they will need adjustments > again, but AFAIK nothing has moved yet, since the ecosystem is still > adapting to the PHP 8 changes (I myself haven't finished adopting it on > many of my libraries). > > If this is relevant to you right now, add an exclusion to your > `phpcs.xml.dist` instead: easier and less painful than expanding the > language for such a tiny detail. > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/ --- ## #114332 — Marco Pivetta — 2021-05-10T09:39:05+00:00 URL: https://externals.io/message/114324#114332 · In reply to: #114331 Hey Matīss > I don't necessarily agree with this point in particular - I mentioned PSR > just-by-driveby, since whoever does follow that convention will face this > issue - but the scope of the proposal is not limited to PSR adopters. It's > also worth pointing out that PSR is not an "official" coding guideline for > PHP, and therefore we should probably not limit the scope to it, simply > because regardless if the brackets are on the same line or not, they are > still there. > > IMO, this is a language issue - topical, cosmetic, and minor - but > language issue nevertheless, in fact, exactly like the one had for > attribute syntax. > > Let's gather some feedback and see. > At language level, `{}` is pretty much "no body" - it's more of an optimization pass for OpCache at that point. Adding AST always comes with major complexity for all the ecosystem: since there is AST isomorphic to the proposal, and it's literally one character in difference, I don't see a clear advantage. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ --- ## #114334 — Guilliam Xavier — 2021-05-10T10:31:20+00:00 URL: https://externals.io/message/114324#114334 · In reply to: #114324 > Hi everyone, > > Since constructor property promotion is now implemented, and it looks > like it could become a widely used feature, I am proposing a small, > cosmetic change in syntax for constructors in concrete classes to do > away with empty constructor body. > > Here's an example of how this would work: > > namespace App; > > class Foo { > public function __construct( > private Bar $bar, > private Baz $baz > ); > } > > Some notes to this: > > - Since this is similar to already existing syntax for body-less > methods, parser should not be affected that much. I hope. I really have > no idea. > - Syntax would be optional - meaning, you can as well continue using > empty body, just that in this case the body would be implied empty. > > Thoughts? > Regards, > - Matīss > > Hi, To me `;` means not "empty body" (that's `{}`) but really "no definition, only declaration" (or "no body, only signature", and also "no code executed"), i.e. an *abstract* method (either explicitly declared so in a class, or implicitly in an interface). Granted, property promotion is already special (cannot be used in an abstract constructor), but it can also be mixed with non-promoted parameters and body, so I feat that your proposed alternative syntax would bring more confusion than convenience :s Regards, -- Guilliam Xavier --- ## #114342 — Chase Peeler — 2021-05-10T14:40:56+00:00 URL: https://externals.io/message/114324#114342 · In reply to: #114334 On Mon, May 10, 2021 at 6:31 AM Guilliam Xavier wrote: > On Mon, May 10, 2021 at 10:29 AM Matīss Treinis > wrote: > > > […] > Hi, > > To me `;` means not "empty body" (that's `{}`) but really "no definition, > only declaration" (or "no body, only signature", and also "no code > executed"), i.e. an *abstract* method (either explicitly declared so in a > class, or implicitly in an interface). > > Granted, property promotion is already special (cannot be used in an > abstract constructor), but it can also be mixed with non-promoted > parameters and body, so I feat that your proposed alternative syntax would > bring more confusion than convenience :s > > Regards, > > -- > Guilliam Xavier > I'm ambivalent about this proposal, but figured I'd throw out one advantage to ; over {}. In my opinion, ending with a semicolon is a very clear way of saying there is no body to the method, while having {} could indicate that implementation of the body was intended but never actually done. I know that when I'm writing new classes I often will set up the method signature but leave the method body empty while I finish the code that utilizes that method. I don't know if that is justification for the proposal, but it is one reason why ; might be preferred over {}. -- Chase Peeler chasepeeler@gmail.com --- ## #114345 — Larry Garfield — 2021-05-10T16:58:01+00:00 URL: https://externals.io/message/114324#114345 · In reply to: #114342 > On Mon, May 10, 2021 at 6:31 AM Guilliam Xavier > wrote: > > > […] > > I'm ambivalent about this proposal, but figured I'd throw out one advantage > to ; over {}. In my opinion, ending with a semicolon is a very clear way of > saying there is no body to the method, while having {} could indicate that > implementation of the body was intended but never actually done. I know > that when I'm writing new classes I often will set up the method signature > but leave the method body empty while I finish the code that utilizes that > method. I don't know if that is justification for the proposal, but it is > one reason why ; might be preferred over {}. > > > -- > Chase Peeler > chasepeeler@gmail.com I agree that in the grand scheme of things this would be a minor matter, but aesthetically I would prefer it as well. The {} annoys me, CS tools or no. Related: I feel the same way about empty-classes and interfaces, which is often the case for exceptions where all you're doing is declaring a type. I figure that would get even more pushback, though. :-) As a data point, you can already do the same "semi-colon for no body" for foreach, for, and while loops. I've only ever done it on foreach to runout an iterator, but it works on all three today. --Larry Garfield --- ## #114346 — Hossein Baghayi — 2021-05-10T17:16:34+00:00 URL: https://externals.io/message/114324#114346 · In reply to: #114345 If constructor is supposed to be empty then why are we even bothering with construction promoting style? Why aren't we sticking to the old way of defining properties? Are there any advantages to using construction promoting style? I mean sure we could have this: class Foo { public function __construct( private Bar $bar, private Baz $baz ); } but in my opinion, the old way of defining them is nice and concise: class Foo { private Bar $bar; private Baz $baz; } What is the point of taking the hard way and then making it convenient? > > > […] > guilliam.xavier@gmail.com> > > […] > have > > […] > definition, > > […] > in a > > […] > would > > […] > advantage > > […] > of > > […] > that > > […] > signature > > […] > that > > […] > > I agree that in the grand scheme of things this would be a minor matter, > but aesthetically I would prefer it as well. The {} annoys me, CS tools or > no. > > Related: I feel the same way about empty-classes and interfaces, which is > often the case for exceptions where all you're doing is declaring a type. > I figure that would get even more pushback, though. :-) > > As a data point, you can already do the same "semi-colon for no body" for > foreach, for, and while loops. I've only ever done it on foreach to runout > an iterator, but it works on all three today. > > --Larry Garfield > > -- > > To unsubscribe, visit: https://www.php.net/unsub.php --- ## #114347 — Sara Golemon — 2021-05-10T17:27:51+00:00 URL: https://externals.io/message/114324#114347 · In reply to: #114328 > > […] > for > > […] > > Given that: > > * `{}` can already represent what you want > * the issue is more of a coding-style related topic > > I suggest bringing this up in a new PSR instead. Consider that PSR-1, PSR-2 > and PSR-12 were designed pre-PHP-8, so they will need adjustments again, > but AFAIK nothing has moved yet, since the ecosystem is still adapting to > the PHP 8 changes (I myself haven't finished adopting it on many of my > libraries). > > A whole lot of agreeing with Marco here. The problem is the coding standard, not the syntax. Also, as Guilliam said in a later reply, using semicolon already has a meaning and this contradicts that. Let's not make the syntax more confusing purely to avoid updating a PSR that was meant to be a living standard. -Sara --- ## #114348 — Larry Garfield — 2021-05-10T17:28:40+00:00 URL: https://externals.io/message/114324#114348 · In reply to: #114346 > If constructor is supposed to be empty then why are we even bothering with > construction promoting style? Why aren't we sticking to the old way of > defining properties? > Are there any advantages to using construction promoting style? > > I mean sure we could have this: > class Foo { > public function __construct( > private Bar $bar, > private Baz $baz > ); > } > > but in my opinion, the old way of defining them is nice and concise: > class Foo { > private Bar $bar; > private Baz $baz; > } > > What is the point of taking the hard way and then making it convenient? 1) Please don't top-post. 2) The reason is that the old way doesn't provide any way to populate them on construction. The pattern of "assign the arg to the prop in the constructor" is stupendously common, and promotion makes it vastly more convenient. For more details: https://platform.sh/blog/2020/php-80-feature-focus-constructor-property-promotion/ The constructor isn't "supposed" to be empty. It just often is with promotion, because the constructor wasn't doing anything else besides shuffling its parameters over to properties, which is now automatic. --Larry Garfield --- ## #114349 — Hossein Baghayi — 2021-05-10T18:01:42+00:00 URL: https://externals.io/message/114324#114349 · In reply to: #114348 > 1) Please don't top-post. > > 2) The reason is that the old way doesn't provide any way to populate them > on construction. The pattern of "assign the arg to the prop in the > constructor" is stupendously common, and promotion makes it vastly more > convenient. > > For more details: > > https://platform.sh/blog/2020/php-80-feature-focus-constructor-property-promotion/ > > The constructor isn't "supposed" to be empty. It just often is with > promotion, because the constructor wasn't doing anything else besides > shuffling its parameters over to properties, which is now automatic. > > --Larry Garfield > > Sorry for top-posting. Didn't know what it means :), also it was kind of my first reply to mailing list. Yes, I see now. I had forgotten that bit when I replied; apologies. I guess it makes sense now to end the constructor with a semicolon when it holds no body. --- ## #114350 — Ben Ramsey — 2021-05-10T18:22:46+00:00 URL: https://externals.io/message/114324#114350 · In reply to: #114349 Hossein Baghayi wrote on 5/10/21 13:01: > > > > […] > Sorry for top-posting. Didn't know what it means :), also it was kind of my > first reply to mailing list. https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md :-) Cheers, Ben --- ## #114352 — Marco Sirabella — 2021-05-10T20:19:55+00:00 URL: https://externals.io/message/114324#114352 > Hossein Baghayi wrote on 5/10/21 13:01: > > […] > > > https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md > :-) To be fair, this rule is easy to miss as a "general hint" at the bottom of the rule page, linked to from [this page](https://www.php.net/mailing-lists.php), which are also mailing list rules I think? The rules located on github are the first time I've seen em, thank you for pointing them out. Additionally, on the "Mailing List Posting guidelines" (the php.net guide): > Don't GPG/PGP sign your messages. If you want people to be able to send you > encrypted email, stick your key-locator in your signature Not sure what the rationale for this one is, and I'm not sure I agree with it, so I'll be breaking it alongside you here. I can't locate the key 0xB9698544 anywhere, though. -- Marco Sirabella --- ## #114369 — Nikita Popov — 2021-05-11T08:58:57+00:00 URL: https://externals.io/message/114324#114369 · In reply to: #114324 > Hi everyone, > > Since constructor property promotion is now implemented, and it looks > like it could become a widely used feature, I am proposing a small, > cosmetic change in syntax for constructors in concrete classes to do > away with empty constructor body. > > Here's an example of how this would work: > > namespace App; > > class Foo { > public function __construct( > private Bar $bar, > private Baz $baz > ); > } > > Some notes to this: > > - Since this is similar to already existing syntax for body-less > methods, parser should not be affected that much. I hope. I really have > no idea. > - Syntax would be optional - meaning, you can as well continue using > empty body, just that in this case the body would be implied empty. > > Thoughts? > Regards, > - Matīss > For what it's worth, I've received the same suggestion from quite a few people. There seems to be an intuitive expectation that only adding a semicolon will work in this case. Personally, I'm okay with allowing it. If we allow it, I would restrict it to specifically the case of a) a promoted constructor b) which has *only* promoted parameters. I don't think we should allow replacing "{}" with ";" for methods in the general case. Regards, Nikita --- ## #114372 — mrtreinis@gmail.com — 2021-05-11T10:17:54+00:00 URL: https://externals.io/message/114324#114372 · In reply to: #114369 Yes, just to clarify the scope of my initial proposal, this should only ever apply to promoted constructors that have 1 or more promoted parameters, and no not-promoted parameters. These would NOT be considered valid: public function __construct( private Baz $baz, Bar $bar ); public function __construct(); public function __construct(Baz $baz); as well as anything not related to __construct. - Matīss On Tue, May 11, 2021 at 10:58, Nikita Popov wrote: > On Mon, May 10, 2021 at 10:29 AM Matīss Treinis > wrote: > > […] > > For what it's worth, I've received the same suggestion from quite a > few people. There seems to be an intuitive expectation that only > adding a semicolon will work in this case. Personally, I'm okay with > allowing it. > > If we allow it, I would restrict it to specifically the case of a) a > promoted constructor b) which has *only* promoted parameters. I don't > think we should allow replacing "{}" with ";" for methods in the > general case. > > Regards, > Nikita --- ## #114373 — Nikita Popov — 2021-05-11T10:40:54+00:00 URL: https://externals.io/message/114324#114373 · In reply to: #114372 > Yes, just to clarify the scope of my initial proposal, this should only > ever apply to promoted constructors that have 1 or more promoted > parameters, and no not-promoted parameters. > > These would NOT be considered valid: > > public function __construct( > private Baz $baz, > Bar $bar > ); > > public function __construct(); > > public function __construct(Baz $baz); > > as well as anything not related to __construct. > > - Matīss > I've put up a quick implementation for this: https://github.com/php/php-src/pull/6972 As this seems somewhat controversial, I'm afraid this change will have to go through the RFC process. Nikita > > > On Mon, May 10, 2021 at 10:29 AM Matīss Treinis > wrote: > > > […] > > For what it's worth, I've received the same suggestion from quite a few > people. There seems to be an intuitive expectation that only adding a > semicolon will work in this case. Personally, I'm okay with allowing it. > > If we allow it, I would restrict it to specifically the case of a) a > promoted constructor b) which has *only* promoted parameters. I don't think > we should allow replacing "{}" with ";" for methods in the general case. > > Regards, > Nikita --- ## #114374 — Bruce Weirdan — 2021-05-11T11:24:18+00:00 URL: https://externals.io/message/114324#114374 · In reply to: #114369 > If we allow it, I would restrict it to specifically the case of a) a > promoted constructor b) which has *only* promoted parameters. I don't think > we should allow replacing "{}" with ";" for methods in the general case. It could also be useful when you want to make sure constructor is *not* defined, e.g. ``` private final function __construct(); ``` (often seen in singleton implementations). -- Best regards, Bruce Weirdan mailto:weirdan@gmail.com --- ## #114381 — mrtreinis@gmail.com — 2021-05-11T13:59:05+00:00 URL: https://externals.io/message/114324#114381 · In reply to: #114373 Oh absolutely, and many thanks for doing the code part, Nikita! I would propose leaving this open for debate till, say, 15th of May here on internals ML to gather more input. If there are no super strong arguments on why this should not happen or go to RFC, I will draft a RFC and from there, the usual process applies. - Matīss > On Tue, May 11, 2021 at 12:17 PM Matīss Treinis > wrote: > > > […] > > I've put up a quick implementation for this: > https://github.com/php/php-src/pull/6972 > > As this seems somewhat controversial, I'm afraid this change will have to > go through the RFC process. > > Nikita > > > > […] --- ## #114385 — Sara Golemon — 2021-05-11T14:33:47+00:00 URL: https://externals.io/message/114324#114385 · In reply to: #114381 > Yes, just to clarify the scope of my initial proposal, this should only > ever apply to promoted constructors that have 1 or more promoted > parameters, and no not-promoted parameters. > Hard disagree. While it's certainly silly/pointless to have a nil constructor when there are non-promoted args present, I think that deliberately making that mode special (read: inconsistent) is the wrong way to go. > These would NOT be considered valid: > public function __construct(); > For example, Niki's reply showed a place where that mode is perfectly reasonable (singleton finals). If you must have this syntactic sugar, then please make it consistent. > as well as anything not related to __construct. > I'd be willing to go along with inconsistency since once you allow syntax you can't unallow it without pain. So while I don't love the tack, I'll follow it if we do this feature. (which IMO we shouldn't). > If there are no super strong arguments on why this should not happen or go > to RFC, I will draft a RFC and from there, the usual process applies. > I think you've heard a number of strong arguments why it should not happen, but I also think this deserves its chance to be fleshed out and voted on, so by all means, do work the RFC. -Sara --- ## #114387 — come.chilliet@fusiondirectory.org — 2021-05-11T14:37:11+00:00 URL: https://externals.io/message/114324#114387 · In reply to: #114369 Le Tue, 11 May 2021 10:58:57 +0200, Nikita Popov a écrit : > If we allow it, I would restrict it to specifically the case of a) a > promoted constructor b) which has *only* promoted parameters. I don't think > we should allow replacing "{}" with ";" for methods in the general case. This would create a subtle difference of allowed syntax between a constructor and an other method, and between a constructor with promoted parameters and without. I think we should avoid this. I even thought we merged changes to make constructors more like the other methods, but I just checked and it seems the RFCs to allow ": void" on constructors were declined. Côme --- ## #114388 — Chase Peeler — 2021-05-11T14:39:39+00:00 URL: https://externals.io/message/114324#114388 · In reply to: #114385 > On Tue, May 11, 2021 at 5:18 AM Matīss Treinis > wrote: > > […] > > Hard disagree. While it's certainly silly/pointless to have a nil > constructor when there are non-promoted args present, I think that > deliberately making that mode special (read: inconsistent) is the wrong way > to go. > > > […] > > For example, Niki's reply showed a place where that mode is perfectly > reasonable (singleton finals). If you must have this syntactic sugar, then > please make it consistent. > > > […] > > I'd be willing to go along with inconsistency since once you allow syntax > you can't unallow it without pain. So while I don't love the tack, I'll > follow it if we do this feature. (which IMO we shouldn't). > > > I agree. I think making things inconsistent between constructors and other methods is something that can be lived with - there are already other things special about constructors that don't apply to other methods - but we should at least allow consistency among constructors and allow the trailing semicolon in all cases. > > On Tue, May 11, 2021 at 8:59 AM Matīss Treinis > wrote: > > […] > go > > […] > > I think you've heard a number of strong arguments why it should not happen, > but I also think this deserves its chance to be fleshed out and voted on, > so by all means, do work the RFC. > > -Sara > -- Chase Peeler chasepeeler@gmail.com --- Next page: https://externals.io/message/114324.md?page=2