On Fri, Mar 15, 2019 at 11:11 AM Nikita Popov <[email protected]> wrote:
>
> On Fri, Mar 15, 2019 at 4:26 PM Nikita Popov <[email protected]> wrote:
>>
>> On Fri, Mar 15, 2019 at 4:16 PM Levi Morrison <[email protected]> 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
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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
