Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112447
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>
In-Reply-To: <31c9d66b-771a-35ed-1b11-c681bbcc02c3@gmail.com>
Date: Sun, 6 Dec 2020 17:00:42 -0800
Message-ID: <CAN2symjwms40cMu3kx44=iSNn5sZZ1jEGeKxfZmLZrQFjJQouQ@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: 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 Sun, Dec 6, 2020 at 7:12 AM Rowan Tommins <rowan.collins@gmail.com> wrot=
e:
>
> On 06/12/2020 00:17, Paul Crovella wrote:
> >> enum cases have no state
> > Unless there's a bit left out from this RFC this is not completely
> > true, you've just limited them to annoying ways of working with data,
> > e.g. static variables.
>
>
> I'm not sure what you mean here, but it sounds a bit like you're saying
> there are ways to emulate mutable state, so why bother restricting it?

Static variables don't emulate mutable state, they are mutable state.
My question is why go out of the way to restrict things arbitrarily,
particularly when the result is ineffective and just makes things suck
more. It's irrelevant extra work to annoy people with no gain.

> The point is that since enum cases are singleton objects, any instance
> state would actually be global across the program, which is probably not
> what people would expect.

Instance state being global is a well-known problem with singletons.
Maybe don't use singletons then. Or simply document them as was done
in the RFC. I'd prefer the former since singletons don't seem to buy
much here but problems, though maybe I'm missing something. In any
case why is static state being (kinda sorta) restricted along with it?

> >> static methods on cases, which without data are exactly the same as no=
rmal methods
> > This is an argument against instance methods, which you kept, rather
> > than static methods, which you didn't. How is this division anything
> > but arbitrary?
>
>
> On a singleton object, instance methods and late static binding are
> equivalent, but instance methods are probably more intuitive, since
> people are more used to writing code like "$this->suit->shape();" than
> "$this->suit::shape();"
>
> I guess both could be supported, but other than more code style
> decisions to make, I can't think of what they'd add.

Consistency. Which reduces both the wtf factor when working with them
and edge cases for other features that interact with them.

> > Again, what is it particular to enums that necessitates adding these
> > inconsistencies to the language? I get that*you*  want to avoid state,
> > but how is that an enum thing rather than a you thing?
>
>
> "Inconsistency" is a straw man here, because these are a brand new
> concept that already does things objects don't do.

Inconsistency is in no way a straw man. This RFC has enums being
implemented as "fancy objects", based on classes, backed by objects,
with the results being treated as classes and objects in every way
except for.. well mostly a bunch of artificial restrictions that
appear to have nothing to do with enums at all.

> So let's flip it
> around: do you have any use cases for directly storing state on an enum
> case, remembering that such state would be unavoidably global?

No, that is a garbage standard that's been abused around here for too
long. This RFC is proposing to introduce inconsistencies into the
language, it's up to it to justify them. It is not up to me or anyone
else to come along and pass your personal code review just to ask for
that justification.

> Restricting them will likely make other desirable features easier - for
> instance, how would serialization work:

Like serialization already works with objects, including singletons.

> $a =3D Suit::Hearts;
> $a->setColour(Colour::Pink);
> $serialized =3D serialize($a); // does this serialize the instance state?
> $a->setColour(Colour::Purple);
> $b =3D unserialize($serialized);
> assert($a =3D=3D=3D $b); // as discussed elsewhere, this should be true
> assert($a->getColour() =3D=3D=3D $b->getColour());  // are they both pink=
?
> both purple?
>
>
> Note that Larry's longer term plan is for "algebraic data types",
> including "tagged unions": https://wiki.php.net/rfc/adts Unlike
> straight-forward enum cases, these are not singletons, and each instance
> has its own associated state.

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.

> Regards,
>
> --
> Rowan Tommins (n=C3=A9 Collins)
> [IMSoP]
>