Hey Rob,
On 01.07.26 17:43, Rob Landers wrote:
On Wed, Jul 1, 2026, at 10:51, Nick Sdot wrote:
Hey Rowan,
On 01.07.26 15:32, Rowan Tommins [IMSoP] wrote:
On 1 July 2026 04:29:48 BST, Nick Sdot<[email protected]>
<mailto:[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
Hi Nick,
First of all, the fact that three people have submitted different
syntaxes (putting aside that I also haven’t shared my preference as
well), should be an indication that it isn’t straightforward; just
from a “what does it look like” perspective.
It isn’t simply “just run this code”.
I would very much ask that you move this discussion to a different
thread. As the RFC author, who rejected it as future scope, I can’t
engage with your proposal here. All I can say is that I reject it for
future scope, repeatedly.
Moving it outside the thread would let people in this thread discuss
the RFC as proposed, and if there’s a consensus in the new thread,
perhaps it could be adopted into this RFC or even proposed as an
immediate following RFC.
Arguing for it here, cuts off my hands and is a distraction.
— Rob
As I said earlier, I disagree that this is unrelated. Calling it a
"distraction" is... I don't know. The very feature your RFC proposes
will create a new problem, because you hold the opinion that preexisting
limitations could just be ignored (or moved to future scope) for a *new*
feature. I think that is wrong, and not good for the language -- which I
had to point out. People actively engaged with my concern in this very
branch of the thread, I responded. That is what the list is for? I,
however, understand that you stick to rejecting; I will not add anything
new and if no one else shares my concern then this branch and topic will
naturally die down.
--
Cheers
Nick
