Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107181
User-Agent: Cyrus-JMAP/3.1.7-237-gf35468d-fmstable-20190912v1
Mime-Version: 1.0
Message-ID: <c409b8c6-d227-45c3-b3c3-aed1ae4e5cba@www.fastmail.com>
In-Reply-To: 
 <CABdc3WpQvFKZJa5y6P0Du-EuAPbuLMi8gPC6OMEdR8ftq1xfyA@mail.gmail.com>
References: 
 <CABdc3Wpit02=BqvVE85ciw9qo3UYc2LBatOy23yFk5z+quZ2rw@mail.gmail.com>
 <CABdc3WqiULGOhdz+s9vmdz=-KnAS=A=XDrj_diimBAKHt-o92A@mail.gmail.com>
 <CALKiJKr_bei94FLTugYTMpKLTswGGOypzZYgiZOtHWAZyEJT3g@mail.gmail.com>
 <CABdc3Wq3aOULZMkRVcA6=JZszjB3e123zCUGtnSRf6qDBnsWtA@mail.gmail.com>
 <CALKiJKpF-V0ubcg-_h06HEvcpjjw8VkVzjeCjA0HAY08Gmm6sQ@mail.gmail.com>
 <CABdc3WpQvFKZJa5y6P0Du-EuAPbuLMi8gPC6OMEdR8ftq1xfyA@mail.gmail.com>
Date: Mon, 16 Sep 2019 16:55:29 -0500
To: internals@lists.php.net
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: [RFC] Object Initializer
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Sep 16, 2019, at 10:16 AM, Micha=C5=82 Brzuchalski wrote:
> Hi Rowan,
>=20
> pon., 16 wrz 2019 o 16:57 Rowan Tommins <rowan.collins@gmail.com>
> napisa=C5=82(a):
>=20
> >
> >
> >>
> >>>
> >>> That would require multiple new features, though, so initializers =
might
> >>> be
> >>> more achievable in the short term, and perhaps there is room for b=
oth,
> >>> particularly if support for getters and setters improves.
> >>>
> >>>
> >> Here again, IIRC you're trying to solve the issue which is off-topi=
c.
> >> 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 w=
ould
> > 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.
> >
>=20
> 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 fea=
tures
> could exist.
>=20
> Regards,
> Micha=C5=82 Brzuchalski


I am not sure I agree here.  As I noted earlier, we're running out of si=
gils.  Suppose initializer syntax used:

new Employee{prop =3D "val"};

Now later we want to add named parameters.  What happens if we use the s=
ame syntax?  Does it mean the same thing, really?  Or does the meaning o=
f 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 cal=
ls, say:

new Employee({ prop =3D "val"});

But now we have two syntaxes that do *almost* the same thing, but with s=
ubtle differences, and the existing positional syntax, which means there=
's now 3 ways to create an object that look very similar visually but me=
an slightly different things.  That's... not good.

I still hold that initializers as described, even though I like the prob=
lem they're solving being solved, are a strict subset of the combination=
 of named parameters and auto-constructor promotion.  If we had those, w=
e would have more functionality and initializer functionality comes for =
free, and it would be more self-evident what was going on, with fewer sy=
ntax variations.  Whereas adding initializers now as a one-off would lik=
ely make adding those later more difficult.

Thus I would rather see time spent on adding those than on a one-off syn=
tax.  (And yes, I fully realize I am saying that as someone not currentl=
y working on any of the above syntaxes and so I'm talking about other pe=
ople doing work, etc.)

--Larry Garfield