Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113038
MIME-Version: 1.0
References: <eadd4a32-a05b-463b-a91f-a5d353c577b2@www.fastmail.com>
 <ffd16d04-498b-46ac-95e7-b4692900a6d3@www.fastmail.com> <CAF+90c8DrGObn36Oeb6Tf90Zw7yPkG9MkabZFti5G0S01nXZ2A@mail.gmail.com>
In-Reply-To: <CAF+90c8DrGObn36Oeb6Tf90Zw7yPkG9MkabZFti5G0S01nXZ2A@mail.gmail.com>
Date: Mon, 1 Feb 2021 16:21:35 +0100
Message-ID: <CAF+90c9KZxM0J8uMKdfHMjC4cXgPJ3L_j9qZea-ZAUvDT-aYpA@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d8855d05ba47e948"
Subject: Re: [PHP-DEV] Re: [RFC] Enumerations, Round 2
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000d8855d05ba47e948
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 1, 2021 at 2:16 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Fri, Jan 29, 2021 at 6:18 PM Larry Garfield <larry@garfieldtech.com>
> wrote:
>
>> On Mon, Dec 28, 2020, at 2:21 PM, Larry Garfield wrote:
>> > Hello, Internalians!
>> >
>> > After considerable discussion and effort, Ilija and I are ready to
>> > offer you round 2 on enumerations.  This is in the spirit of the
>> > previous discussion, but based on that discussion a great deal has bee=
n
>> > reworked.  The main change is that Enumeration Cases are now object
>> > instances of the Enumeration class rather than their own class.  Most
>> > of the other changes are knock-on effects of that.
>> >
>> > Of particular note:
>> >
>> > * Cases may not have methods or constants on them.  They're just dumb
>> values.
>> > * Enums themselves may have methods, static methods, or constants.
>> > * Traits are supported, as long as they don't have properties.
>> > * The value() method on scalar enums is now a property.
>> >
>> > The full RFC is here, and I recommend reading it again in full given
>> > how much was updated.
>> >
>> > https://wiki.php.net/rfc/enumerations
>> >
>> > The implementation is 98% complete; there's still a few lagging bits i=
n
>> > reflection, and some opcache bugs that Ilija is still stomping on.
>> >
>> > There are a few outstanding questions listed that we would like
>> > feedback on.  We're not entirely certain which direction to go with
>> > them, for reasons explained in the RFC.  Input on those is especially
>> > welcome.
>> >
>> > Happy New Year.  May it be enumerable.
>>
>> And we're back again.  The RFC has been updated with a steady stream of
>> smaller improvements based on feedback and testing, and is now in its Fi=
nal
>> Form(tm) (we think).  The only major change worth noting is that we rena=
med
>> things. :-)
>>
>> An enum with no scalar backing is now called a Pure Enum, made up of Pur=
e
>> Cases.  One that does have backing values is called a Backed Enum, made =
up
>> of Backed Cases.  That change is mainly to allow for future expansion to
>> non-scalar backing static values, should the use case arise.  Reflection
>> was also reworked a bit to make it more logical.
>>
>> https://wiki.php.net/rfc/enumerations
>>
>> At this point, Ilija and I consider the RFC done and ready for a vote.
>> Baring any major issues being brought up, we plan to start the vote in t=
he
>> first half of next week, probably Tuesday-ish.  If you have any other bu=
g
>> reports or tweaks, please speak now or forever hold your patches.
>>
>> --Larry Garfield
>>
>
> Two notes:
>
> > =E2=80=9Cenum=E2=80=9D becomes a language keyword, with the usual poten=
tial for naming
> conflicts with existing global constants.
>
> ... and class names, which is probably more relevant here. It's worth
> noting that this RFC renders many existing enum libraries unusable, such =
as
> myclabs/php-enum, which defines an "abstract class Enum".
>
> > Both Pure Enums and Backed Enums implement an internal interface named
> IterableEnum
>
> I really don't like this interface name. We have an "iterable" type in
> PHP, and having an IterableEnum that is not ... iterable would be somewha=
t
> confusing. IIRC you previously called this UnitEnum, which is also not
> great in that "unitary enum" is not particularly well-established
> terminology, but I think it's still better than IterableEnum.
>
> Regards,
> Nikita
>

I'm also not really happy with the ReflectionEnumPureCase vs
ReflectionEnumBackedCase split in the reflection API. I think there should
be some form of common base here. That could be ReflectionEnumBackedCase
extends ReflectionEnumCase extends ReflectionClassConstant, or it could be
ReflectionEnumUnitCase extends ReflectionClassConstant, where
getBackingValue() can return null (previous design). What was the
motivation for switching to two "unrelated" classes?

One more thing I'm missing in the RFC and implementation both is an API for
declaring enums from PHP extensions. As far as I can tell, this is
currently not possible.

Nikita

--000000000000d8855d05ba47e948--