Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107172
MIME-Version: 1.0
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>
In-Reply-To: <CABdc3Wq3aOULZMkRVcA6=JZszjB3e123zCUGtnSRf6qDBnsWtA@mail.gmail.com>
Date: Mon, 16 Sep 2019 15:57:01 +0100
Message-ID: <CALKiJKpF-V0ubcg-_h06HEvcpjjw8VkVzjeCjA0HAY08Gmm6sQ@mail.gmail.com>
To: =?UTF-8?Q?Micha=C5=82_Brzuchalski?= <michal@brzuchalski.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b6937e0592acd1fd"
Subject: Re: [PHP-DEV] Re: [RFC] Object Initializer
From: rowan.collins@gmail.com (Rowan Tommins)

--000000000000b6937e0592acd1fd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 16 Sep 2019 at 15:37, Micha=C5=82 Brzuchalski <michal@brzuchalski.c=
om>
wrote:

>
>
>> The problem with that is that you need an extra static method to make us=
e
>> of it, and you still need to get the arguments into that method. It migh=
t
>> be useful occasionally, but it still doesn't help constructors which are
>> setting a large number of private / protected properties.
>>
>>
> This RFC is not trying to help those constructors but tries to simplify
> instantiation objects and initializing properties
> there where any kind of constructor won't help, but rather would be
> unnecessary at all.
>


I realize that, I was responding to a specific point: you said that the
syntax would work for protected or private properties if used where those
are visible. I was saying that I don't think that combination would be used
very often, so it's easiest to just discuss the public property case.



> You wouldn't want to put 15+ arguments in your constructor to initialize
> public properties which
> don't need other validation than proper type, right?
>
> Even if it would be just adding "public" keyword in front of them.
>


Why not? You've got to list those 15 properties somewhere; if the syntax
was such that you only needed to list them once, it makes no difference
whether we call the result "class initializer" or "automatic constructor
with 15 named parameters", IMO.



>
>
>> Either of those, with named parameters, would be almost indistinguishabl=
e
>> from object initializers at the call site. Depending on the syntax chose=
n,
>> it might be as similar as:
>>
>> // Call initializer, requires public properties
>> new Employee { age =3D> 42, name =3D> 'John Smith' };
>> // Call constructor, requires special constructor definition
>> new Employee( age =3D> 42, name =3D> 'John Smith' );
>>
>>
> Last RFC treating about named arguments has similar syntax with curly
> braces, but all together with previous ones
> tries to solve the issue through additional syntax inside parentheses,
> which means both features can coexist together.
>
> Calling instantiation always used parentheses as the way to pass
> constructor arguments let's keep it that way.
> Using object-initializer would use curly braces - just like it's used to
> be solved in other languages.
>



My intention here was just to show that using named parameters would be
just as concise as using an object initializer; I just picked a pair of
syntaxes that were as similar as possible to illustrate that.




>
>
>>
>> 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.

Regards,
--=20
Rowan Tommins
[IMSoP]

--000000000000b6937e0592acd1fd--