Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109447
MIME-Version: 1.0
References: <CAJmjfvW8b=jYTjLfW9N9FT_eQVS7RBe768NZXv-g4V2RM3OgtA@mail.gmail.com>
 <CAJmjfvUcONYKvRKvAXB8x5n3faRwxntbg5q25Nan2aZrSNznXQ@mail.gmail.com> <CAAKU0unR5dX8nu4wQs1zaE0nRBMqB4MhfofF3PBvaxEEV98c2w@mail.gmail.com>
In-Reply-To: <CAAKU0unR5dX8nu4wQs1zaE0nRBMqB4MhfofF3PBvaxEEV98c2w@mail.gmail.com>
Date: Mon, 30 Mar 2020 10:17:01 +0200
Message-ID: <CAF+90c-DLuoW-7H4Xka9wPZBHmg5vDu=_Awky0u_Qx1KTHEsQA@mail.gmail.com>
To: Levi Morrison <levi.morrison@datadoghq.com>
Cc: Jakob Givoni <jakob@givoni.dk>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005756f205a20e14db"
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000005756f205a20e14db
Content-Type: text/plain; charset="UTF-8"

On Mon, Mar 30, 2020 at 3:06 AM Levi Morrison via internals <
internals@lists.php.net> wrote:

> The current RFC text is not consistent with using `=` or `=>` for the
> assignments. The assignment `=` is vastly more common, though, and I
> don't understand why if we are using an array syntax we aren't using
> `=>`.
>
> I intend to vote no. I agree that we need to do something in this
> space, but this is not it. I don't want perfect to be the enemy of
> good either, but I think this still needs more work. Maybe interested
> parties (including me) can collaborate off-list somewhere?
>

This is going to be a "no" vote from me as well. I don't think it's really
possible to "save" this proposal though, at least if it remains as syntax
sugar to perform multiple property assignments to one object. The syntax
has two use-cases: Object initialization and everything else. I don't think
it's doing a good job at solving object initialization, for reasons that
others (and in particular Larry) have already pointed out in detail. And I
don't really see a use case for this kind of mass property assignment
outside of object initialization.

I don't have much of a problem with the limitation to public properties (I
love public properties!), the problem why this is unsuitable for object
initialization is more that it is in practice mutually exclusive with
constructors. You can either have a class that defines a constructor, in
which case you can't use COPA with it (as the constructor would be doing
the initialization -- ignore the argument-less case here), or you have a
class without a constructor, in which case you essentially must use COPA.

There's also no migration pathway between these two modes, in that
switching between them is a backwards compatibility break for library
consumers. And if it turns out that an object needs non-trivial
construction logic at a later time, you can not easily introduce it without
breaking COPA style initialization.

This problem is not really limited to this proposal, it's a general problem
of retrofitting object initialization syntax to a language that
traditionally did not have it, and it doesn't seem to be an easy problem to
solve.

Regards,
Nikita

--0000000000005756f205a20e14db--