On Sat, Dec 5, 2020, at 2:26 PM, Larry Garfield wrote:
> On Fri, Dec 4, 2020, at 5:24 PM, Larry Garfield 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
> 
> Thank you everyone for the feedback so far!  I've updated the RFC with 
> a few changes, based on discussion here and elsewhere:
> 
> * Clarified that "enums behave like objects unless otherwise 
> specified."  That should clarify a lot of edge case questions.  (Which 
> is specifically one of the reasons to build off of objects.  We can 
> inherit answers to most edge cases.)
> * Primitive-backed Cases have been renamed to Scalar Enums, because 
> "Primitive-backed" is just too clumsy to say or write all the time.
> * There's now formal internal interfaces defined for Enum, UnitEnum, 
> and ScalarEnum to define the methods mentioned.  These serve as both 
> documentation and to allow user-space code to tell when a value it's 
> dealing with is an enum, and a particular type of enum.  (And therefore 
> what enum methods are available.)
> * Added a value() method to ScalarEnum, to make it easier to get at the 
> scalar equivalent arbitrarily.
> * Fixed a bunch of typos.
> * Updated the reflection section to have getType() return a 
> ReflectionType rather than a bare string.
> 
> (The patch will be updated for the above shortly as Ilija's time allows.)

Another update:

Based on feedback here, and after further discussion with Ilija and NIkita, 
we're going to try a different tack on some implementation details.  
Specifically:

* We're going to shift Enums to be a single class with a bunch of secret 
properties inside to hold the different case object instances, rather than a 
class per case.  That should make the overall memory usage lower, especially 
for enums with a large number of cases.  As an unfortunate side effect, this 
will preclude per-case methods, at least for now. :-(
* The ReflectionCase class will naturally go away at that point.
* For serialization, we'll introduce a new serialization marker, enum, which 
will make it feasible too round-trip an enum while maintaining singleton-ness.  
More specifically, the deserialize routine would essentially become 
$type::from($value), where $type and $value are pulled from the serialized 
version.

I was also wrong in one of my earlier statements; as currently implemented, 
enum cases are implemented as class constants that reference an object.  
(Something the engine is allowed to do even if user code cannot.)  That means 
they *do* work as parameter defaults and can be assigned as a default value of 
an object property or constant.  Huzzah!

Because it's the holidays these changes won't be immediate, but expect us to 
come back in a few weeks with the next draft.

Thank you everyone for your interest!

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to