Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112680
User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396
Mime-Version: 1.0
Message-ID: <7f4049fc-18a9-47ae-87ff-ef2a24009df3@www.fastmail.com>
In-Reply-To: 
 <CAAwdEzCLVsaoWhmOV8PnELQwaWeUjCJeomqr12H8f1KesKZnQg@mail.gmail.com>
References: <eadd4a32-a05b-463b-a91f-a5d353c577b2@www.fastmail.com>
 <CAAwdEzCLVsaoWhmOV8PnELQwaWeUjCJeomqr12H8f1KesKZnQg@mail.gmail.com>
Date: Wed, 30 Dec 2020 13:45:50 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Enumerations, Round 2
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Dec 30, 2020, at 4:12 AM, Alexandru P=C4=83tr=C4=83nescu wrote:

> Nice evolution overall.
>=20
> Few notes:
> - I think ScalarEnum::fromValue() would be more clear than just from()=
 and
> more in sync with ->value property.

Any name would work, I suppose.  I prefer short, single-word methods whe=
re possible, myself.

> - For the class structure you gave an example to illustrate the 'simil=
ar'
> way it is related to class, it would be nice to also mark the class as=

> final.

It would.  Added.

> - I agree with no state behavior, at least at this point. However, I w=
ould
> have liked to offer the ability for very easy creation of
> singleton/multiton patterns using enums, like in Java.

I'm not sure what you're describing here.  Do you mean tagged unions/ADT=
s, which are punted to a later RFC? =20

https://wiki.php.net/rfc/tagged_unions

> - Enums evolve in time and cases are added or sometimes removed. When =
the
> storage of the case stays externally (as scalar values or serialized),=

> there could be issues when some of them are removed in the meantime.

Possibly; though that's no different than a class evolving or going away=
 in time.  Either way it's up to the developer to figure out what BC str=
ategy makes sense.

>   - for ScalarEnum::from(), for missing values I would guess we will t=
hrow
> an exception, maybe a specific one? Can we mention it in the RFC?

It already says a ValueError is thrown.  It probably does make sense to =
subclass that, though.  I'll mention it to Ilija.

>   - for deserialization, how should it be handled? using an exception =
as
> well, same exception as in the previous case.

Ilija and I discussed this a bit, and settled on an invalid deserialiati=
on issuing a warning and returning false.  An exception would probably b=
e better, but right now deserialize() doesn't throw things so introducin=
g that just for enums seems inconsistent.  He'll be updating the impleme=
ntation shortly.

> - The allowed_classes option on unserialize() method, I'm guessing it =
will
> work with Enums just like every other class, putting an instance of
> __PHP_Incomplete_Class?

Enums don't have unsafe behavior in their constructors the way classes d=
o, so we're not convinced there's a reason to exclude them.  For now all=
owed_classes does not include enums.

> - Inheritance would work between enums. But only by eliminating some c=
ases.
> I can see how enum RedSuites could extend enum Suites without breaking=
 LSP.
> Not sure if it makes sense to dig on this now.
>=20
> Regards,
> Alex

Possibly as a future scope, if we see demand for it.  The RFC is ambitio=
us enough as is and already has several follow-ups planned for more adva=
nced cases. :-)

Cheers!

--Larry Garfield