Feature Request: multiple class property initialization without constructor

[blacktrs]

Description

With constructor property promotion we're already achieved ability to skip a lot of boilerplate code. With property accessors (aka hooks) we could rid of getters and setters. But often classes need constructors only to set properties. And in such cases, constructors become redundant.

Thus, we would have possibility to skip constructors to initialize multiple properties at once:

readonly class User
{
   public string $name;
   public int $age;
}

$user = new User {
    name: "John",
    age: 42,
};

As a result, classes would be initialized in struct-like way. In looks like useful additional for "data" classes/DTOs etc.

I suppose it was discussed but was unable to find exact rfc or discussion.

[cmb69]

I suggest you write to the Internals list.

[iluuu1994]

Hi @blacktrs. Similar things have been proposed before. Some comments:

1. This is very very similar to constructor-promoted properties and named parameters:

readonly class User {
    public function __construct(
        public string $name,
        public int $age,
    ) {}
}

$user = new User(
    name: "John",
    age: 42,
);

There is a little bit more boilerplate in the class itself, but the definition also only occurs once per DTO. So, the visual benefit is marginal.

2. With this definition:

Thus, we would have possibility to skip constructors to initialize multiple properties at once:

What happens when the DTO adds a constructor? Do you then need to go back and convert all of your { to (? And if you forget any cases, you get potentially buggy behavior.

If it is just to drop the public function __construct() {} boilerplate, then I would ask:

a. Do we really need that? Isn't constructor property promotion short enough?
b. If we can achieve the same without also changing the initialization syntax, wouldn't that be preferable? For example, some people in the past have suggested:

readonly class User(
    public string $name,
    public int $age,
);

This is closely related to a recent thread: https://externals.io/message/125975 One of its goal is very similar: To drop boilerplate for short DTOs. My criticism there was pretty much the same. Since we have such a similar discussion open, I will close this issue. Please feel free to join the discussion on the list.

[blacktrs]

Thanks for the discussion link, I will take a look.

What happens when the DTO adds a constructor? Do you then need to go back and convert all of your { to (? And if you forget any cases, you get potentially buggy behavior.

It may be irrelevant right now, but it should be the same approach as the current one when properties are being overwritten. I think there are no differences in the behavior when someone wants to set one or multiple properties at the same time.

class User
{
   public function __construct(
      public string $name,
      public int $age,
   ) {
   }
}

// properties are overwritten
$user = new User ("J. Doe", 43) {
    name: "John",
    age: 42,
};

// as, in this case
$user = new User ("J. Doe", 43);
$user->name = "John";
$user->age  = 42;

[iluuu1994]

@blacktrs You are right. But at least you'll get an error at runtime, and static analysis can also catch this for you. Edit: I might have misread your comment, I am not sure. If {} may be used in addition to the constructor, it might make more sense to go for a syntax that is applicable not only to constructors. E.g. https://wiki.php.net/rfc/compact-object-property-assignment

[blacktrs]

@iluuu1994 I believe the syntax is not the most important thing here, so I completely agree it could be applicable in more cases, e.g. when cloning.

However, it might not be absolutely related to records as per the discussion above, it is more like some syntax sugar around public property assigning.

[iluuu1994]

Indeed, https://wiki.php.net/rfc/compact-object-property-assignment is likely closer to what you were asking for. The vote failed, but it's been quite a few years and maybe internals is more open to this now. If you want to pursue this, you can follow the first step in the RFC process: https://wiki.php.net/rfc/howto

Email internals@lists.php.net to measure reaction to your intended proposal. State who would implement the feature, or whether the proposal is only a “concept”. Proceed with an RFC if feedback is not negative or if a detailed RFC will clarify the proposal. Mail list subscription is at http://php.net/mailing-lists.php. (Reminder: always "bottom post" your replies. Never “top post”.)

[blacktrs]

@iluuu1994 thank you
I will take a look at the RFC process and would try to contribute to PHP in case my knowledge of C will cover such functionality.

[iluuu1994]

Also note that you don't technically need to provide an implementation for an RFC, and maybe something who likes the idea will volunteer. And if you'd like to provide it yourself, we have some channels with people that can help out. https://php.github.io/php-src/#how-to-get-help