Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104757
MIME-Version: 1.0
References: <5c8b20af.1c69fb81.c8b33.d2faSMTPIN_ADDED_MISSING@mx.google.com>
 <CAFMT4Npcr=VwXUMTO8svKF4SAeAsF5TWzz8HAgB4nTR0sCQg+Q@mail.gmail.com>
 <CAF+90c8mbR=qZT6PSRog5bMH--mHxXrwe3NzoL6UYLi8yebfVw@mail.gmail.com> <CAF+90c9CDyNbobwwHT__YEPqAyUot+odiAqMnw=J6X+hPuZV7w@mail.gmail.com>
In-Reply-To: <CAF+90c9CDyNbobwwHT__YEPqAyUot+odiAqMnw=J6X+hPuZV7w@mail.gmail.com>
Date: Fri, 15 Mar 2019 11:39:51 -0600
Message-ID: <CAFMT4NrspCwdGEKcb2e_c7xku6GDkkY3FHfpYS9CtZJcFpqjBA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Kenneth Ellis McCall <xellisx@gmail.com>, internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [Proposal] Struct Data Types
From: levim@php.net (Levi Morrison)

On Fri, Mar 15, 2019 at 11:11 AM Nikita Popov <nikita.ppv@gmail.com> wrote:
>
> On Fri, Mar 15, 2019 at 4:26 PM Nikita Popov <nikita.ppv@gmail.com> wrote=
:
>>
>> On Fri, Mar 15, 2019 at 4:16 PM Levi Morrison <levim@php.net> wrote:
>>>
>>> Personally, I think pass by-value with copy-on-write semantics like
>>> arrays is the sweet spot. Mutability is fine if it is localized.
>>
>>
>> If we introduce something like this, I think it is very important that i=
t does not use the same property access syntax as ordinary objects, which a=
re not copy-on-write. I do not want to be second guessing whether $x->y =3D=
 $z is going to copy or not. Possibly such struct types should indeed use t=
he array access syntax, because array access is generally copy-on-write (th=
e exception being ArrayAccess objects).
>>
>>>
>>> I think having a no-constructor construction syntax is also a good
>>> idea. I've discussed it with a few people, but don't can't remember if
>>> it's ever been brought up on-list. Basically, the idea is to use a
>>> JSON-like syntax with the type-name in front, and I think it can be
>>> fine to use on regular classes that don't have a constructor too:
>>>
>>>     struct Point2d {
>>>       float $x;
>>>       float $y;
>>>     }
>>>
>>>     $origin =3D Point2D { x: 0, y: 0 };
>>>
>>> This syntax has no conflicts. We could also add an object literal
>>> syntax for creating ad-hoc stdClass objects like so: `$obj =3D { x: 1,
>>> y: 1}`. This has an ambiguity, but I believe I have solved the issue
>>> without too much trouble once before.
>>
>>
>> This syntax has no conflicts in the sense that the grammar is unambiguou=
s, but I believe it does conflict under LR(1). The problem is the alternati=
ve array access syntax, which makes Point2D { x } currently valid syntax. W=
e can distinguish it at the ":", but by this point a shift/reduce descision=
 on "{" must have already been made. (We can likely hack around this.)
>
>
> Taking back this one: Turns out that we currently don't support the CONST=
ANT{$x} syntax -- it's an oversight from the uniform variable syntax RFC, w=
hich generally established syntax parity for the [] and {} array access syn=
tax, but missed support for this particular case. In this case it happens t=
o be in our favor :)
>
> Nikita

I have a proof-of-concept grammar for the brace construction syntax
(without anonymous object literals) here:

    https://github.com/morrisonlevi/php-src/tree/brace-construction

Right now it discards the type name, and then compiles the
brace-construction as an array.

At least in the short term, I won't be fleshing it out at all, so if
anyone wants to take it and run, that's fine. I need to be fixing up
the co- and contra-variance patch for 7.4 and doing QA on it.