Re: [Proposal] Struct Data Types

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 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.