On Fri, Dec 4, 2020 at 7:00 PM Larry Garfield <la...@garfieldtech.com> wrote: > > > Dec 4, 2020 7:37:51 PM Paul Crovella <paul.crove...@gmail.com>: > > > On Fri, Dec 4, 2020 at 3:25 PM Larry Garfield <la...@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-small task, so we've broken it up into several stages. The first > >> stage, unit enumerations, are just about ready for public review and > >> discussion. > >> > >> The overarching plan (for context, NOT the thing to comment on right now) > >> 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 > >> mostly 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 > >> la...@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 reintroduced > with tagged unions, but for now methods relating to state would just be > confusing. > * we couldn't figure out what possible use they'd have (like static methods > 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 normal > 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 anyway. > Magic methods except for those specifically listed below - Most of the > excluded 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? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
