Hey Rowan,
On 01.07.26 15:32, Rowan Tommins [IMSoP] wrote:
On 1 July 2026 04:29:48 BST, Nick Sdot<[email protected]> wrote:
```
final readonly class Dog(
string $name,
)extends Animal {
parent::__construct($name);
}=> {
// class body }
```
The above:
- does NOT have a parent constructor shortcut call -> `extends Animal`
- DOES allow parent constructor call in primary constructor body
- behaves exactly (!) as a conventional constructor; in fact syntax sugar
```
final readonly class Dog(
string $name,
)extends Animal($name)// already IS the parent constructor call... {
// hence, here no parent constructor call allowed }=> {
// class body }
```
The above:
- DOES have a parent constructor shortcut call -> `extends Animal($name)`
- does NOT allow parent constructor call in primary constructor body
- *no difference in parent constructor calling behaviour to what the RFC pr
ooposes now*
...
So where is the complexity?
So now we have to specify:
- a brand new syntax for putting a code block outside the class body
- a parser rule to detect parent conductor calls (is
ParentClassName::__construct also forbidden? What about
DeeperAncestor::__construct?)
- the order of operations if there's a body and a shorthand parent call
- maybe other details of how the constructor body works which I haven't thought
of
As with the rest of the feature, to make the proposed changes work in
the class header, yes. :)
Of course *any* parent constructor call would be forbidden from the body
if the parent shorthand is used. The "already IS the parent... hence,
here no parent..." gives no room for interpretation, I think.
The order could be discussed, and a default (probably after, because
that's how it seem to work without body) be agreed on. Since there would
be a body, manually calling the parent constructor would be possible if
the default doesn't suit ones intend.
I still don't see an explosion of complexity.
What would justify not allowing the body that helps to address a real problem?
Many people see having more than one way to write the same thing as a cost,
which needs to be outweighed by some benefit.
I'm on the fence whether primary constructors as they are in the current RFC
are worthwhile; they're a tidy shorthand for a common case, but not saving that
much over existing constructor promotion.
With your proposal to make them just a different way of writing any constructor, using a
weird new syntax which puts code outside of the class body, I would be a definite
"no".
That's just my opinion of the cost-benefit balance.
Bit sad to see that there is not even the will to discuss it. But fair,
everyone can have their opinion. Then I hope the "on the fence" will
eventually be a "no". Because there is IMO no reality where introducing
this without bodies, and hence with no solution to the issues I pointed
out, is easier to reason about than what I propose here. Just imagine
you have to refactor an existing class with a primary constructor.
`readonly` would prevent what you want to do and must be removed. This
would require you to check and refactor the whole class, instead of just
adding a body. It doesn't make sense.
We don't need more half finished, half not working, confusing features
in PHP.
Rowan Tommins
[IMSoP]
--
Cheers
Nick
