On Mon, Sep 16, 2019, at 10:16 AM, Michał Brzuchalski wrote:
> Hi Rowan,
>
> pon., 16 wrz 2019 o 16:57 Rowan Tommins <rowan.coll...@gmail.com>
> napisał(a):
>
> >
> >
> >>
> >>>
> >>> That would require multiple new features, though, so initializers might
> >>> be
> >>> more achievable in the short term, and perhaps there is room for both,
> >>> particularly if support for getters and setters improves.
> >>>
> >>>
> >> Here again, IIRC you're trying to solve the issue which is off-topic.
> >> Improving protected and private properties initialization through
> >> constructor is not the main target of current RFC.
> >>
> >
> >
> >
> > I don't think it's off-topic to consider whether a related feature would
> > make this one redundant. However, you've picked a weird sentence to reply
> > to, because I'm agreeing with you, that the two features could exist side
> > by side without being redundant.
> >
>
> Sorry for that, the quoted sentence was left unintentionally and yes, it's
> not off-topic.
> Had to rethink what I was trying to say, but I do think both these features
> could exist.
>
> Regards,
> Michał Brzuchalski
I am not sure I agree here. As I noted earlier, we're running out of sigils.
Suppose initializer syntax used:
new Employee{prop = "val"};
Now later we want to add named parameters. What happens if we use the same
syntax? Does it mean the same thing, really? Or does the meaning of that call
syntax vary depending on whether the constructor is defined in such a way to
make it support named parameters? What happens when it could mean either, but
the result would be different? Or do we have to guarantee that the result is
the same, even if that means limiting one or the other?
That could be avoided by using some other syntax for named parameter calls, say:
new Employee({ prop = "val"});
But now we have two syntaxes that do *almost* the same thing, but with subtle
differences, and the existing positional syntax, which means there's now 3 ways
to create an object that look very similar visually but mean slightly different
things. That's... not good.
I still hold that initializers as described, even though I like the problem
they're solving being solved, are a strict subset of the combination of named
parameters and auto-constructor promotion. If we had those, we would have more
functionality and initializer functionality comes for free, and it would be
more self-evident what was going on, with fewer syntax variations. Whereas
adding initializers now as a one-off would likely make adding those later more
difficult.
Thus I would rather see time spent on adding those than on a one-off syntax.
(And yes, I fully realize I am saying that as someone not currently working on
any of the above syntaxes and so I'm talking about other people doing work,
etc.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
