Le 08/12/2020 à 18:40, Larry Garfield a écrit :
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

Hello,

I'm really glad to see all of you working hard on this, I have nothing more interesting to say than "Thank you", all of you, very much.

And for the record I didn't say so because I didn't want to raise any flame or troll, but now that Nikita put it on the carpet, I'm free to say that implementation choices did make me fear for performances, but they are implementation details, and future can always improve it. Now I don't fear anymore, thanks !

Have a good confined holidays all !

Regards,

Pierre

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

Reply via email to