Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104756
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>
In-Reply-To: <CAF+90c8mbR=qZT6PSRog5bMH--mHxXrwe3NzoL6UYLi8yebfVw@mail.gmail.com>
Date: Fri, 15 Mar 2019 18:11:12 +0100
Message-ID: <CAF+90c9CDyNbobwwHT__YEPqAyUot+odiAqMnw=J6X+hPuZV7w@mail.gmail.com>
To: Levi Morrison <levim@php.net>
Cc: Kenneth Ellis McCall <xellisx@gmail.com>, internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003345fd058425212e"
Subject: Re: [PHP-DEV] [Proposal] Struct Data Types
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000003345fd058425212e
Content-Type: text/plain; charset="UTF-8"

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 it
> does not use the same property access syntax as ordinary objects, which are
> not copy-on-write. I do not want to be second guessing whether $x->y = $z
> is going to copy or not. Possibly such struct types should indeed use the
> array access syntax, because array access is generally copy-on-write (the
> 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 = 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 = { 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 unambiguous,
> but I believe it does conflict under LR(1). The problem is the alternative
> array access syntax, which makes Point2D { x } currently valid syntax. We
> 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
CONSTANT{$x} syntax -- it's an oversight from the uniform variable syntax
RFC, which generally established syntax parity for the [] and {} array
access syntax, but missed support for this particular case. In this case it
happens to be in our favor :)

Nikita

--0000000000003345fd058425212e--