Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113041
MIME-Version: 1.0
References: <eadd4a32-a05b-463b-a91f-a5d353c577b2@www.fastmail.com> <ffd16d04-498b-46ac-95e7-b4692900a6d3@www.fastmail.com>
In-Reply-To: <ffd16d04-498b-46ac-95e7-b4692900a6d3@www.fastmail.com>
Date: Mon, 1 Feb 2021 19:48:09 +0200
Message-ID: <CAAwdEzAzQ+0qW2KyJ7JeDQwFJTDRThWWaZBeddRvCQ8FQmXV-g@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000520f805ba49f6fd"
Subject: Re: [PHP-DEV] Re: [RFC] Enumerations, Round 2
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--0000000000000520f805ba49f6fd
Content-Type: text/plain; charset="UTF-8"

On Fri, Jan 29, 2021 at 7:17 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 been
> > 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 in
> > 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 Final
> Form(tm) (we think).  The only major change worth noting is that we renamed
> things. :-)
>
> An enum with no scalar backing is now called a Pure Enum, made up of Pure
> 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 the
> first half of next week, probably Tuesday-ish.  If you have any other bug
> reports or tweaks, please speak now or forever hold your patches.
>
> --Larry Garfield
>
>
Hi,

Maybe IterableEnum can actually be just Enum. As you are not allowed to
implement it and/or define it, wouldn't it work? That's how it's named
internally in Java, not that it would matter but sometimes people forget
it's just syntactic sugar there as well (
https://docs.oracle.com/javase/8/docs/api/java/lang/Enum.html): public
abstract class Enum<E extends Enum<E>> implements Comparable<E>,
Serializable.

Also in the interface I think you can include the name property, similarly
with how you did in BackedEnum interface.
https://wiki.php.net/rfc/property_accessors will probably allow it to be
clearly defined at some point.

A bit it bothers me that backed enums are very easy to implement even
without the special case and just a simple Enum would be fine.
I mean even if you will have a backed enum, with would be simple and
probably the need will come at some point to have also a public function
getLegacyValue(): string and a public static function
fromLegacyValue(string $value): Enum.
But yes, using backed values is a common pattern so I'm guessing it's a
valuable important use case.

For storing in a database purpose, property name can be used directly, I
think.
It would nice to have in the rfc the recommended way to retrieve the Enum,
given that you know the name.
I'm guessing that would be Suit::$name;

Thanks,
Alex

--0000000000000520f805ba49f6fd--