Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113042
User-Agent: Cyrus-JMAP/3.5.0-alpha0-84-gfc141fe8b8-fm-20210125.001-gfc141fe8
Mime-Version: 1.0
Message-ID: <3261e170-636c-4645-b42f-4c14c2d9c5eb@www.fastmail.com>
In-Reply-To: 
 <CAAwdEzAzQ+0qW2KyJ7JeDQwFJTDRThWWaZBeddRvCQ8FQmXV-g@mail.gmail.com>
References: <eadd4a32-a05b-463b-a91f-a5d353c577b2@www.fastmail.com>
 <ffd16d04-498b-46ac-95e7-b4692900a6d3@www.fastmail.com>
 <CAAwdEzAzQ+0qW2KyJ7JeDQwFJTDRThWWaZBeddRvCQ8FQmXV-g@mail.gmail.com>
Date: Mon, 01 Feb 2021 13:29:42 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: [RFC] Enumerations, Round 2
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Feb 1, 2021, at 11:48 AM, Alexandru P=C4=83tr=C4=83nescu wrote:


> > https://wiki.php.net/rfc/enumerations
> >
> > At this point, Ilija and I consider the RFC done and ready for a vot=
e.
> > 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 othe=
r bug
> > reports or tweaks, please speak now or forever hold your patches.
> >
> > --Larry Garfield
> >
> >
> Hi,
>=20
> Maybe IterableEnum can actually be just Enum. As you are not allowed t=
o
> 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 forg=
et
> 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.

We tried that.  The `enum` keyword precludes any class or interface bein=
g called `Enum`, even internally.

> Also in the interface I think you can include the name property, simil=
arly
> 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.
>=20
> 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 functi=
on
> 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.

It's more about standardizing the API.  An ORM can rely on a backed enum=
 always exposing its "value to save to the DB" at ->value, rather than i=
t sometimes being ->value(), sometimes ->legacyValue(), sometimes ->asIn=
t(), etc.

> 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 E=
num,
> given that you know the name.
> I'm guessing that would be Suit::$name;

That doesn't work for referencing a constant; it gets read as a static p=
roperty.  That's a more general syntactic question for PHP, and one we'r=
e not going to solve here. :-)  Really, ->name is more an implementation=
 artifact.  If you want to have a primitive to pass around, for whatever=
 reason, that's what a backed enum is for.

--Larry Garfield