Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112505
MIME-Version: 1.0
References: <d1c4689e-9120-4e90-837c-a1b3eac63cd6@www.fastmail.com>
 <CAN2symh0kEQRa+1DxRAzJHrdqmQFP2xnjKGd1wmsfU_Lv9rH=A@mail.gmail.com>
 <32277b43-079d-4cd7-a159-8ad555096742@garfieldtech.com> <CAN2symgz-4BoLMUUyQMRXAzzCBB3nf+p160UJyB0H-LCFThXvw@mail.gmail.com>
 <31c9d66b-771a-35ed-1b11-c681bbcc02c3@gmail.com> <CAN2symjwms40cMu3kx44=iSNn5sZZ1jEGeKxfZmLZrQFjJQouQ@mail.gmail.com>
 <5e92a320-49fc-41b0-8969-338d62c98419@www.fastmail.com>
In-Reply-To: <5e92a320-49fc-41b0-8969-338d62c98419@www.fastmail.com>
Date: Mon, 14 Dec 2020 14:43:56 -0800
Message-ID: <CAN2symhCO6THvoeOQMbNEW=pAJOFh23cfghgGANSe2OxYepxKg@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Enumerations
From: paul.crovella@gmail.com (Paul Crovella)

On Tue, Dec 8, 2020 at 10:14 AM Larry Garfield <larry@garfieldtech.com> wro=
te:
>
>
> Hi Paul.  Although we're on hold for a bit while Ilija makes some changes=
 in direction (see previous email)

I'm looking forward to seeing the results.

>
> Enumerations, as a general concept, are stateless.  Or rather, the idea o=
f state doesn't even apply to them.

They're (enumerated) lists of things. You need a way to make a list,
identify an item as being on the list, and differentiate it from other
items on the list.

> The integer 5 doesn't have any state of its own.  All instances of the in=
teger 5 are logically identical to all other instances of the integer 5.

For simple types like integers, sure. Objects however can carry
additional data around without interfering with identifying or
differentiating them. It doesn't matter if object 5 has my address
book, is wearing a funny hat, or just cached the results from a bunch
of expensive method executions - you can still identify it and
distinguish it just fine.

> That the PHP RFC for enums uses objects internally is incidental.

This is a complete reversal from what you've otherwise written in and
about the RFC.

> So if you're defining, say, an enum for cardinal directions (North, South=
, East, West), There are literally only 4 possible values for that type, an=
d those values must always be equal to themselves.  Attaching "5 miles" to =
"South" in one script and "2 km" to "South" in another script is nonsensica=
l, just like attaching "feet" to the number 5 and later changing it to "fin=
gers" just doesn't make any sense at all.

Whether or not an object holding other data makes sense is irrelevant
to enums. Take it up in code review.

> It is true that, if you're attaching operations to enum cases that have n=
o state, a method, a static method, and a constant are often interchangeabl=
e.  A constant is strictly less capable since it cannot have logic, but a m=
ethod and static method are functionally equivalent.  The reason for forbid=
ding static methods and constants is largely simplicity.

You've significantly added to the WTF factor and edge cases when
working with them. For example enums can implement interfaces. Except
interfaces with constants. Or maybe you can implement interfaces with
constants, you just don't inherit the constants. Wait no that'd break
type declarations. Perhaps then you can inherit constants from
interfaces but you still can't declare them yourself. So the way to
use constants in enums is to declare them on an interface and
implement that to inherit them. Maybe.

This isn't simplicity. None of these options makes working with enums bette=
r.

Whether you prefer constants, static methods, or instance methods
isn't even relevant to enums. Again take it up in code review.

> For example, the change I just discussed in my previous email about switc=
hing to a single class with instances as constants means that static method=
s can only be on the enum (Suit), because there is no per-case-class to put=
 them on (Diamonds).  The same is true of per-instance constants.  If we'd =
promised that those things worked, we wouldn't be able to make this change.

The thing never shipped, you can make any change you want. If you're
pretending it did ship then you couldn't make that change anyway
without breaking instance methods so your point is moot.

> If when the dust settles there's a good reason to expand the functionalit=
y further in ways that still don't violate "South =3D=3D=3D South," (such a=
s adding constants to the enum type itself, perhaps) those can be considere=
d at that time.

As you've said elsewhere:

> Because enums are based on classes, there's not really any added complexi=
ty. They inherit the ability to have methods from being classes. It would b=
e more work to separate it.

The same holds for constants, static methods, properties, (traits? do
these even work? some of them?) This isn't about adding functionality,
it's about not arbitrarily removing it.

> As both Rowan and I mentioned, the long-term plan includes future RFCs fo=
r other functionality such as tagged unions.  If you want state,

I want a coherent enum RFC that isn't complicated by unrelated
personal preferences being shoehorned into it. If you want to make an
RFC to deprecate class constants in favor of methods - fine, but at
least make the RFC about that. Trying to wedge it in here half-assed
only creates problems.

> then what you want is not an enum but a tagged union.

You're saying this as if they're necessarily different things.

> For whatever reason, most languages with tagged unions seem to build them=
 into and onto enums.

Languages that implemented enums such that they function as tagged
unions saved themselves the effort of making the same thing twice.
They also saved their users from dealing with whatever subtle
differences would've been included to distinguish them.

> I'm not entirely sure why, and I'm honestly not 100% convinced that's the=
 right approach in PHP, but that's a debate for a future RFC.

Any debate about enums is appropriate for this RFC.

> Within the scope of this RFC, enums must always obey "South =3D=3D=3D Sou=
th", and thus must be stateless.

South =3D=3D=3D South can hold with or without state and isn't even require=
d
for enums. All you need is to know it's on the list and for it to be
distinguishable from others on the list.

> > Longer term plans are irrelevant except to avoid inadvertently
> > shutting the door on something. This RFC is up for discussion, and
> > will be up for voting, in isolation. It has to be able to stand on its
> > own.
>
> This is true up to a point.

The point is nothing in the RFC is contingent on the others. If this
RFC passes and none of the others do, or none of the other work gets
done, that has to be okay. This means treating this RFC on its own.

As you said at the beginning:

> The overarching plan (for context, NOT the thing to comment on right now)

Yet you keep bringing it up...

> Explicitly setting up a series of RFCs like we're doing is, as far as I a=
m aware, novel for PHP.  It's the correct way to handle a larger task like =
this, however, especially when there clear division points that "chunk" the=
 work in natural ways.  Even if enums in this RFC are the only thing that p=
asses, that's still a major win for PHP.  It's not as big a win as tagged u=
nions with robust pattern matching and generics on the side would be, but i=
t's still a big step forward.  By breaking it into chunks, we make it more =
likely that as much as can be done will get done, and approved, and into th=
e language, even if the end result is the same feature set when 8.1.0 gets =
tagged.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>