Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112437
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>
In-Reply-To: <32277b43-079d-4cd7-a159-8ad555096742@garfieldtech.com>
Date: Sat, 5 Dec 2020 16:17:30 -0800
Message-ID: <CAN2symgz-4BoLMUUyQMRXAzzCBB3nf+p160UJyB0H-LCFThXvw@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 Fri, Dec 4, 2020 at 7:00 PM Larry Garfield <larry@garfieldtech.com> wrot=
e:
>
>
> Dec 4, 2020 7:37:51 PM Paul Crovella <paul.crovella@gmail.com>:
>
> > On Fri, Dec 4, 2020 at 3:25 PM Larry Garfield <larry@garfieldtech.com> =
wrote:
> >>
> >> Greetings, denizens of Internals!
> >>
> >> Ilija Tovilo and I have been working for the last few months on adding=
 support for enumerations and algebraic data types to PHP.  This is a not-s=
mall task, so we've broken it up into several stages.  The first stage, uni=
t enumerations, are just about ready for public review and discussion.
> >>
> >> The overarching plan (for context, NOT the thing to comment on right n=
ow) is here: https://wiki.php.net/rfc/adts
> >>
> >> The first step, for unit enumerations, is here:
> >>
> >> https://wiki.php.net/rfc/enumerations
> >>
> >> There's still a few bits we're sorting out and the implementation is m=
ostly done, but not 100% complete.  Still, it's far enough along to start a=
 discussion on and get broader feedback on the outstanding nits.
> >>
> >> I should note that while the design has been collaborative, credit for=
 the implementation goes entirely to Ilija.  Blame for any typos in the RFC=
 itself go entirely to me.
> >>
> >> *dons flame-retardant suit*
> >>
> >> --
> >> Larry Garfield
> >> larry@garfieldtech.com
> >
> > I'd like to see the specific reasons for the restrictions listed in
> > Comparison to objects[1]. In general if something's value is even
> > debatable then the default position should be to remain consistent
> > with the rest of the language. It should take a strong argument to
> > introduce any artificial limitation and it's useful to have that in
> > the RFC.
> >
> > [1] https://wiki.php.net/rfc/enumerations#comparison_to_objects
> >
> The reasoning general comes down to one of 2 things:
>
> * they involve state, and enum cases have no state. They may get reintrod=
uced with tagged unions, but for now methods relating to state would just b=
e confusing.
> * we couldn't figure out what possible use they'd have (like static metho=
ds on cases, which without data are exactly the same as normal methods.)
>
> --Larry Garfield

Thank you for updating the RFC.

> 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.

> static methods on cases, which without data are exactly the same as norma=
l 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?

> Constructors - Not relevant without data/state.
> Destructors - Not relevant without data/state.

This doesn't explain the need to remove them. What problem do they cause?

> Enum/Case constants - Not necessary as methods fulfill the same use case.

How is this specific to enums? Why is it necessary to add this
inconsistency to the language in this RFC? What happens to constants
inherited from interfaces?

> Enum/Case properties - Not necessary as methods fulfill the same use case=
, plus we want to avoid state.
> Dynamic properties - Avoid state. Plus, they're a bad idea on classes any=
way.
> Magic methods except for those specifically listed below - Most of the ex=
cluded ones involve state.

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? What happens to
properties gained from traits?