Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123134
Precedence: bulk
MIME-Version: 1.0
References: <CAPyj-LBMQEJ=2BF=xk_on4O2xTU+MM2XRAZ5g=uPwVOf=bh+sw@mail.gmail.com>
 <CAJp_myUm_aPF8ZTehwYPcybEJ1KQ9zZnoa5OKNda9cqgw4VMQQ@mail.gmail.com>
In-Reply-To: <CAJp_myUm_aPF8ZTehwYPcybEJ1KQ9zZnoa5OKNda9cqgw4VMQQ@mail.gmail.com>
Date: Mon, 15 Apr 2024 01:44:46 +0200
Message-ID: <CAPyj-LCGDeUX+h6shWKcEx6avq+Dzee3A6feCMUgyAqDrTXSvg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][Vote announcement] Property hooks
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Matthew

We're going to skip over the reiterations of Juliettes arguments, as
they have already been responded to.

On Thu, Apr 11, 2024 at 12:08=E2=80=AFAM Matthew Weier O'Phinney
<mweierophinney@gmail.com> wrote:
>
> On Mon, Apr 8, 2024 at 4:41=E2=80=AFPM Ilija Tovilo <tovilo.ilija@gmail.c=
om> wrote:
>>
>> https://externals.io/message/122445#122667
>>
>
> 2. I'm not a huge fan of the short syntax, but the improvements in the mo=
st recent draft are _mostly_ ones I can live with. The part that's still un=
clear is when and where hooks need a `;` termination, and _why_ the `;` is =
used, instead of `,`. When using `match()` expressions, you use `,` to sepa=
rate the expressions, but for some reason, the proposal uses `;` ... but on=
ly when using short expressions. And if you have a full-form mixed with a s=
hort form, the `;` is only needed for the short-form expression. This feels=
 arbitrary, and it will be easy to get it wrong for people comfortable with=
 `match()` statements.

I agree that the distinction of `,` and `;` isn't clear-cut. I would
categorize hooks as declarations, because they are really just
functions attached to the property. Declarations are `;`-terminated,
or have a body (`{}`) (properties, (non-)abstract methods, class
consts, etc). `,`, on the other hand, is used for lists of expressions
and other things (array elements, match cases, function arguments).

The other argument for the syntax we chose is that it's already used in C#.

> (Larry tells me that it's `match()` being weird here, but considering tha=
t for many developers, their only point of reference for this sort of synta=
x IS `match()`, making it feel like the language is ignoring its own syntax=
 when creating new syntax.)

Given my description from above, I don't believe this is true either.
Match arms most closely relate to the array element syntax, which
already uses `,`.

> 3. While I'd likely prefer Marco's approach to references (just don't all=
ow them), the fact that they mirror how `__get()` and `__set()` _currently_=
 work gives a migration path for users who are familiar with that paradigm'=
s gotchas. In other words, it's consistent with the current language, and w=
ill make migrating from `__set/__get` to hooks easier. It's a lot of comple=
xity, but the table you created helps with that. That table MUST make it to=
 the docs for the feature!

Precisely. Our decision to support references (as much as possible)
comes from the desire to maintain compatibility (as much as possible),
not only with `__get`/`__set` but also plain props.

Ilija