Hey Tim,
On 30.06.26 03:37, Tim Düsterhus wrote:
Hi
Am 2026-06-29 21:20, schrieb Nick Sdot:
Well, this is going to be more of a general thing, nothing exclusive
to your RFC... But this is how we end up with more and more half
finished and awkward (to not say broken) features in PHP. While I
understand and generally support "get the minimum in and iterate
later" from the perspective of RFC authors, reality shows that
"later" can be either years later or very likely never at all.
Though, we will have to deal with the unfinished/broken "minimum"
solutions. How many more of these do we want to add?
To name three from the top of my mind:
1/ we still don't have stringable enums
2/ we still don't have a solution for widening the type of a promoted
property's set hooks (hi #16638), and of course
3/ my beloved readonly hooks themselves. ;)
I consider (1) and (3) to be fundamentally wrong from a semantic
perspective, i.e. a “Won’t fix”, not a missing feature.
For (2) I agree that the situation is unfortunate, but as you say:
[…] See my comment to #16638; we probably should just have skipped
hooks on promoted properties unless there would have been a solution
before release.
… here the correct fix would've been making the feature *smaller*
rather than *larger*, which is the opposite of what you are proposing
here.
And for this RFC I agree with Rob that not allowing an explicit body
with “primary constructors” is the correct choice to prevent
confusion: The limitations are a feature that makes classes using
“Primary Constructors” easy to reason about. “Reduce typing” alone is
not a sufficiently strong argument in favor of a new feature. As an
example, promoted properties are not just “fewer characters to type”,
but have the added benefit of “keeping data types in sync between
parameter and property”, thus reducing mistakes. I don't see such a
benefit for primary constructors if they are capable of doing
everything a regular constructor can.
Yes, as I proposed back then. However, I disagree. Making it "smaller"
is not always automatically the solution. Here it is making it bigger.
Because making it bigger makes primary constructor behave the same way
as conventional constructors (with the benefit to be in the class
header, which I find awesome). I don't see why I should not be allowed
to write something like this:
```
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?
It offers the same functionality as a normal constructor. It also would
not prevent parent class constructor shortcuts or whatever. It in fact
would not change/remove anything the RFC wants, and it is purely
additive. If my understanding of Rob is correct, we just would need to
find an agreement on how parent constructor stuff works.
“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.
Best regards
Tim Düsterhus
--
Cheers
Nick
