Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87015
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAHXmDMAEo0iYXRjWKEpEh+Ode8Qhq88Ozo1d1_kJcL_043_Nrw@mail.gmail.com>
References: <CAF+90c_4xiYu36Jx-1Y8u9V-8kZLhN-jp4Dv8+psU8LFT36+2Q@mail.gmail.com>
	<CAHXmDMAEo0iYXRjWKEpEh+Ode8Qhq88Ozo1d1_kJcL_043_Nrw@mail.gmail.com>
Date: Sat, 4 Jul 2015 10:56:10 +0200
Message-ID: <CAF+90c9NJOaBtwKxzfY5Fu53L-LgrzHZCHrcV_o6=12ejCMPxw@mail.gmail.com>
To: Trevor Suarez <rican7@gmail.com>
Cc: PHP internals <internals@lists.php.net>, Levi Morrison <morrison.levi@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bf0bfc20f9af3051a08d881
Subject: Re: [PHP-DEV] [RFC] Additional soft-reservations for PHP 7
From: nikita.ppv@gmail.com (Nikita Popov)

--047d7bf0bfc20f9af3051a08d881
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Jul 4, 2015 at 9:31 AM, Trevor Suarez <rican7@gmail.com> wrote:

>
> On Fri, Jul 3, 2015 at 12:24 PM Nikita Popov <nikita.ppv@gmail.com> wrote=
:
>
>> Hi internals!
>>
>> In a previous thread on the topic [1] I promised to create an RFC for th=
e
>> soft-reservation of 'void', similar to a bunch of other reservations we
>> have done for PHP 7. The RFC also includes 'enum' as an additional
>> independent proposal, as I think this will likely be needed in 7.x. If y=
ou
>> have further suggestions for names or keywords that we are likely to nee=
d,
>> please point them out.
>>
>> https://wiki.php.net/rfc/additional_soft_reservations_for_php7
>>
>> Thanks,
>> Nikita
>>
>> [1]: http://markmail.org/message/ovvnz5p2o6q7ebjl
>
>
> Yea, this is smart to get this going. I think it makes a lot of sense. I'=
d
> love to see "struct" added to this list, so we could potentially add a
> value object structure of some sort down the road.
>
> As far as "prior art", you can see that there's already some interest in
> this area:
>
> - https://twitter.com/auroraeosrose/status/616321058904350720
> - https://gist.github.com/auroraeosrose/2036d1d675a4bd254450
> - https://gist.github.com/Antnee/237334e1eb937892ad7a
>
> Anyway, yea. Makes sense to me. =F0=9F=91=8D
>

So there are two questions to answer here:

a) How likely is it that this will be implemented in the near future? I've
added "enum" to the list, because there is already an existing proposal,
which I personally consider relatively likely to pass. Structs are as-yet a
vague concept and may be implemented in very different ways. As far as I
see the only fundamental difference between a "struct" and a "class" per
the above definition is that you can't create dynamic properties on it -
which is something that can be solved from a different angle as well
(declare strict mode).

b) Do we really need a keyword to implement this feature? For example,
instead of "struct Foo {}" we could use the syntax "struct class Foo {}",
in which case the new "keyword" would be "struct class" and we do not cause
BC issues. Note that this also applies to "enum" where we could use "enum
class Foo {}" instead. This syntax has precedent in C++11. Thinking about
this now, this might be a better option, because there's a lot of code
using "enum" in name segments [1] (it's pretty much the natural choice for
userland enum implementations...) and introducing this keyword might result
in a non-trivial amount of breakage (cc Levi). "struct" looks less
problematic [2].

Nikita

[1]: https://github.com/search?l=3DPHP&p=3D1&q=3Denum&type=3DCode&utf8=3D%E=
2%9C%93
[2]:
https://github.com/search?l=3Dphp&q=3Dstruct&ref=3Dsearchresults&type=3DCod=
e&utf8=3D%E2%9C%93

--047d7bf0bfc20f9af3051a08d881--