On Sat, Dec 5, 2020, at 8:21 AM, Marc Bennewitz wrote:
>     *dons flame-retardant suit*
> 
> Hi Larry,
> 
> thanks for your great initiative and hard work in this!
> I'm the author of an emulated enumeration lib [1] and really looking 
> forward seeing native enumeration support in PHP.
> 
> Here are some questions about your RFC:
> 
> * How can you access a defined case value? 
>   Something like `Suit::Spades->value()`

At the moment it's only accessible via the ::cases() method.  It may be 
appropriate to yoink the ->value() or ->value name to access it another way.  
We're debating that right now.

The primitive equivalent case is tricky, because other languages have about 14 
different ways to think about it, all of them in the end incompatible. :-)  We 
know we don't want to just have "fancy constants," but for those cases you do 
want/need a primitive instead (mainly writing to a DB or screen) it needs to be 
easy enough to get that.  There's a number of competing priorities we're trying 
to balance here to make the DX as clean as possible.

To also respond to Pierre here, at present the primitives must be unique.  We 
want to minimize the boilerplate that people have to write on every enum for 
common cases, and the cases() method is part of that.  It won't capture 
everything, obviously, but if the common cases can be made trivial and the rare 
cases possible, that's a win.

> * Are the cases case-insensitive or case-sensitive?
>   `Suit::Spades` vs. `Suit::SPADES`

They end up as class names internally, so I believe that means they'd be case 
insensitive.

> * Are cases serializable?
>   `Suit::Spades === unserialize(serialize(Suit::Spades)) // true`

Right now they'd do the same as objects, so they'd serialize as an object.  
Unserializing like that, though... hm, that would probably NOT still be === due 
to the way PHP handles objects.  That's probably undesireable, but I'm not sure 
at the moment the best way around that.  I'll have to discuss with Iliya.

> * Do cases have a stable ordinal number / position and is that 
> accessible?
>   This would be very interesting on implementing an optimized EnumSet 
> using bit-array / bit-set internally

The order returned from cases() is stable as lexical order, but there's no 
ordinal number to access.  If you want a bit set, you could do:

enum Permissions: int {
  case Read = 0x1,
  case Write = 0x10,
  case Exec = 0x100,
}

Right now there's no support for case ReadWrite = self::Read | self::Write.  I 
don't know if that would be easy to add in the future, but I'd be OK with it if 
so.  Mainly this runs into the same tricky questions around primitive 
equivalent handling (and what we can coax the lexer to do).

> * I often use metadata in enumerations and so I would be very 
> interested to allow constants.
>   I do understand that they share the same naming table and these needs 
> to be unique but disabling constants altogether would limit the 
> use-cases in my opinion.

That's what methods are for, or potentially __get.  Allowing even 

> * Is it possible to detect / type-hint if something is any enum?
>   ` Suit::Spades instanceof Enum`
> 
>   This basically means that all enumerations would to based on a 
> general enum.
>   This would be very helpful on providing functionalities especially 
> for enumerations thinking about a doctrine enumeration type or again an 
> EnumSet / EnumMap.

Not at the moment.  We're discussing the implications of adding that.

What exactly are EnumSet and EnumMap, in your mind?

--Larry Garfield

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

Reply via email to