Hey Tim,
On 30.06.26 04:27, Tim Düsterhus wrote:
Hi
Am 2026-06-29 22:06, schrieb Nick Sdot:
```
final readonly class Foo(Collection|array $value) implementsBar {
$this->items = $value instanceof Collection ? $value : new
Collection($value);
}=> {
// class body private Collection $items
}
```
How is this not easy to reason about? How is this not *less* confusing?
By introducing `=> {` as a new syntactical pattern that we don't
currently have and where we would need to figure out whether that
pattern would be consistent with existing use of `=>`. My gut feeling
is “it isn’t”.
I have literally zero strong opinion on how the syntax must look like;
as mentioned in my very first answer to Rowan (discussion 1), this is
meant to illustrate the concept and placement, not syntax.
I'm also noting that your example doesn't declare the `$items`
property, which to me is an indicator that it actually isn't that easy
to reason about.
It does declare it; for some reason it just slipped up behind the "class
body" comment -- which is not the case in my sent mails.
“Reduce typing” alone is not a sufficiently strong argument in favor
of a new feature.
Not sure how reduce typing is related to the argument I am making? My
point is that I *want* primary constructors, but that they should
allow bodies to have the same workarounds at hand to deal with
readonly and hook issues as with conventional constructors.
The stated goal of the RFC (from the introduction) is: “removing […]
boilerplate”. It specifically does so by allowing to omit `public
function __construct`, `parent::__construct`, and a pair of braces.
Personally I don't see much value in “just avoid typing some
characters”. However for “logic-less” classes that just store some
values, I can see where the proposal is coming from and the guarantee
that the constructor actually is “logic-less” is some - small -
benefit over “avoid typing characters that your IDE will autocomplete”.
This small benefit would entirely go away by allowing arbitrary logic
in the constructor - and then as you said we would “[…] need to find
an agreement on how parent constructor stuff works”, which is adding
*extra* semantics that folks need to learn onto a feature that is
supposed to make things *simpler*.
Quoting myself: "usage of parent constructor shortcut forbids manual
parent constructor calling, and vice versa. Makes sense to me, and
sounds easy to reason about."
Staying with your example above, but declaring `$items`, I've come up
with the following:
final readonly class Foo(Collection|array $value) implements Bar {
$this->items = $value instanceof Collection ? $value : new
Collection($value);
} => {
public Collection $items;
// class body private Collection $items
}
final readonly class Foo implements Bar {
public Collection $items;
public function __construct(Collection|array $value) {
$this->items = $value instanceof Collection ? $value : new
Collection($value);
}
// class body private Collection $items
}
I find the latter *much* clearer.
Great, then you are lucky, because you *can* write it that way. Now
allow me too writing it how I want writing it and everyone is happy! <3
Best regards
Tim Düsterhus
--
Cheers
Nick
