[RFC][Draft] Body-less __construct

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 mrtreinis@gmail.com
wrote:

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/

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.

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

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?

On Mon, May 10, 2021 at 6:31 AM Guilliam Xavier <
guilliam.xavier@gmail.com>
wrote:

On Mon, May 10, 2021 at 10:29 AM Matīss Treinis mrtreinis@gmail.com
wrote:

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:

<?php
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

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

--

To unsubscribe, visit: https://www.php.net/unsub.php

Le 10/05/2021 à 18:58, Larry Garfield a écrit :

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

I didn't saw this answer at first, but I agree that:

interface MyLibraryException;


class DefaultMyLibraryException extends \RuntimeException implements 
MyLibraryException;

Is an excellent use case for this!

Regards,

Pierre

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 mrtreinis@gmail.com
wrote:

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 mrtreinis@gmail.com
wrote:

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:

<?php
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

My thought here is that a constructor with (only) promoted properties is
hardly a constructor at all -- it's more like a special syntax for
declaring properties that happens to re-use the constructor notation,
because that allows it generalize in certain ways. It could have been
implemented with some other syntax that didn't explicitly mention
constructors at all, such as class Point($x, $y, $z) {} or something.

Agreed. I've personally been a little hesitant to start using CPP because
of this. Declare constructor parameters AND declare properties AND
magically provide a constructor implementation that sets their values. It
looks like a constructor, but it's actually a little different. For me,
this proposal would really help clear that up.

When I see a method with an empty body, I think "this method does have an
implementation, and that implementation does exactly nothing." In the case
of CPP, this isn't true. The method appears to do exactly nothing, but in
fact it has an automatically defined implementation that sets the
properties to the given values.

When I see a semi-colon-terminated method, I think "this method has no
implementation here; one will be provided from somewhere else." This is
the case in abstract classes and interfaces--the subclass provides the
implementation. And it's the case in CPP too--an implementation that sets
the properties to the given values is automatically provided. For this
reason, I don't see it as inconsistent. The semi-colon means someone else
will provide an implementation, and CPP does just that.

Regards,
--Matthew