[RFC] Enumerations

Dec 4, 2020 7:37:51 PM Paul Crovella paul.crovella@gmail.com:

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
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 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?

Le 05/12/2020 à 12:14, Markus Fischer a écrit :

Hi,

I think that ::cases() should always return an array/iterable without
keys, and let userland write their own code to create hashmaps with
those when they need it. I think that having one case (non primitive
cases) that doesn't yield string keys and the other (primitive cases)
which holds string keys may create a confusion because behavior is
different.

If behavior is different, this would mean you couldn't mix primitive
and non primitive cases on the same enum, which, why not couldn't we
do that?

I've no strong feelings and I think your idea makes sense.

But I would argue, of course without having hard facts, that the
majority will have the use-case for a 1:1, aka array with key =>
value, mapping.

Thus I would argue that having (considering your proposal being added)
still such functionality would be useful for a very wide-audience
without everyone having to reinvent a helper method to use the iterable.

I agree with that last statement about wide-audience usefulness,
nevertheless my opinion is that it's not about being useful to the most
but bring consistency at the language level. If for consistency I have
to write an array_map() call whenever I need a choices list, I'm good
with that. Moreover, bringing enum is a thousands times more useful than
having a sugar candy method for building hashmaps !

There are many use cases you'd want an hashmap out of those enums, but
each use case will probably differ in subtle ways. I'd more comfortable
with a coherent behavior that everyone will understand easily, with no
behavior subtleties, and each user implement its need on this side.

Why not, in that case, just add another method than ::cases(), such as,
I don't know, ::to[Hash]Map() for example ?

Regards,

Pierre

Le 05/12/2020 à 15:42, Larry Garfield a écrit :

Another question, about match() behavior:

This usage requires no modification of |match|. It is a natural
implication of the current functionality.

May be this could be the time to have a "strict match", using enums, we
can "statically" guess if branches are missing (of course, whenever you
use default it valid to miss branches) - one thing I'd love is PHP to
throw a fatal error when compiling a match expression whose missing
branches, and not wait until runtime to fail.
I think that would make a great follow-up, but it's out of scope for now. Having match statically know what the available types are when the variable type isn't yet known (because it's in another file) is... I don't know how to do that. That's a broad problem across PHP, frankly. If we can figure out a way to do so, I'd support adding it in the future. (I can't speak for Ilija, but I suspect he would be on board as well.)

--Larry Garfield

Yes, I guess that's a broad problem that could only be fixed with
package handling at the language level, and autoloading done by the
compiler and not userland (simply put, that can only be fixed by killing
autoloading once for all). But that's a much more complex and
bikeshedding topic. Let's consider that your RFC is good as it is (and
it is honestly, I love it).

Regards,

Pierre

Le 05/12/2020 à 00:24, Larry Garfield a écrit :

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

Another question, about match() behavior:

This usage requires no modification of |match|. It is a natural
implication of the current functionality.

May be this could be the time to have a "strict match", using enums, we
can "statically" guess if branches are missing (of course, whenever you
use default it valid to miss branches) - one thing I'd love is PHP to
throw a fatal error when compiling a match expression whose missing
branches, and not wait until runtime to fail.

I think that would make a great follow-up, but it's out of scope for now.
Having match statically know what the available types are when the variable
type isn't yet known (because it's in another file) is... I don't know how
to do that. That's a broad problem across PHP, frankly. If we can figure
out a way to do so, I'd support adding it in the future. (I can't speak
for Ilija, but I suspect he would be on board as well.)

Static analysis can (should?) be taken care of by any of the tools
available for PHP. Wouldn't it be a waste of effort to try to include it in
the runtime parser as well?

• 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.

I guess what it comes down to is whether / how easily a class can return
an existing instance when asked to unserialize, rather than setting
properties on an existing instance. That is, given the string
"C:4:Suit:6:{Spades}" can the class definition return the appropriate
singleton for Suits::Spades rather than a newly constructed object?

If this proves tricky to implement, it would probably be better to
forbid serialization than using the default object format and breaking
the singleton-ness of the case objects.

Regards,

--
Rowan Tommins (né Collins)
[IMSoP]

Hi Larry Garfield,

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.

At a glance, it seems like it's doable in php 8.1 internals to make the unserializer return a singleton if you override the C unserialize callback of the class (this could introduce edge cases during unserialization failure for destruction, expected to be solvable).
This would require using the C: serialize() encoding (php uses that for classes implementing Serializable), not o:
(unserialize can be set to a generic C function that creates a value and puts it in *object*)

// Zend/zend.h
struct _zend_class_entry {
	/* .... serializer callbacks */
	int (*serialize)(zval *object, unsigned char **buffer, size_t *buf_len, zend_serialize_data *data);
	int (*unserialize)(zval *object, zend_class_entry *ce, const unsigned char *buf, size_t buf_len, zend_unserialize_data *data);

// ext/standard/var_unserializer.c, in object_custom()
	if (ce->unserialize == NULL) {
		zend_error(E_WARNING, "Class %s has no unserializer", ZSTR_VAL(ce->name));
		object_init_ex(rval, ce);
	} else if (ce->unserialize(rval, ce, (const unsigned char*)*p, datalen, (zend_unserialize_data *)var_hash) != SUCCESS) {
		return 0;
	}

(I'm one of the maintainers of https://pecl.php.net/package/igbinary , an alternative binary php serializer)

• Tyson

Am 05.12.20, 16:08 schrieb "Larry Garfield" larry@garfieldtech.com:

> 
> * 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.

For me it doesn't really matter how to get the primitive value as long as there is a simple way to do so.

As you wrote

Passing a Primitive Case to a primitive-typed parameter or return will produce the primitive value in weak-typing mode, and produce a TypeError in strict-typing mode.
This would already break simple function calls like the following on strlen

enum Suit: string {
case Hearts = 'H';
...
public function label(): string { return 'Label of ' . $this . ' with length ' . strlen($this); }
// or more clear in my opinion
public function label(): string { return 'Label of ' . $this->value . ' with length ' . strlen($this->value); }
}

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.

I agree here that the defined primitives needs to be unique as well.

> * 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).

> * 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?

An EnumSet is a set (unique cases) of the same enumeration type.
An EnumMap maps cases of the same enumeration type to another value.

The interesting part here is that this can be done in a very efficient way without the need to iterate over it.
Like you have defined an enumeration of 200 countries

enum Country: string {
case USA = 'US',
case Germany = 'DE',
case Australia = 'AU',
...
}

$set1 = Country::USA | Country::Germany; // EnumSet<Country> of [Country::USA, Country::Germany]
$set2 = Country::USA | Country:: Australia; // EnumSet<Country> of [Country::USA, Country::Australia]
$set3 = $set1 & $set2; // EnumSet<Country> of [Country::USA]
$set4 = $set1 & ~$set2; // EnumSet<Country> of [Country:: Germany]

This could of course also be done without operator overloading but it looks very clean with them __
All done internally using bit operations __

Greetings Marc

--Larry Garfield

-- 

To unsubscribe, visit: https://www.php.net/unsub.php

Am 05.12.20, 16:21 schrieb "Rowan Tommins" rowan.collins@gmail.com:

(Apologies if this posts twice, I may have accidentally hit send before 
I'd finished writing it)



> * 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

If you want to associate a stable value with each case, you can use a 
"primitive-equivalent enum" and assign each case an integer manually. As 
the RFC says:

 > There are no auto-generated primitive equivalents (e.g., sequential 
integers).


I think that's a good design decision, because the language itself can't 
actually guarantee a stable ordinal number if the enum's author makes 
changes; e.g. given:

enum Colour { case RED; case GREEN; case BLUE; }

somebody might decide the cases should be in alphabetical order:

enum Colour { case BLUE; case GREEN; case RED; }

It seems unnecessarily confusing to have this be a breaking change 
because code somewhere relied on the ordering. It's much clearer if the 
author has to declare an intentional value, and can then maintain it 
when making cosmetic changes to their own code:

enum Colour { case BLUE=3; case GREEN=2; case RED=1; }

Sorry for the confusion - I mean stable within the same process - not over different processes / systems.

> * I often use metadata in enumerations and so I would be very 
> interested to allow constants.


Could you give an example what you mean? Metadata on individual cases is 
supported by methods, which map more cleanly to things like interfaces, 
and the notion of each case as a singleton object, not a static class.


That said, I have a related question: can enum cases be used as the 
*value* of constants? e.g.:

class OldMaid {
     public const SUIT = Suit::Spades;
     public const VALUE = CardValue::Queen;
}


If so, this leads to an interesting use case for constants on the enum 
itself (not the cases) to define aliases:

enum Suit {
   case Hearts;
   case Diamonds;
   case Clubs;
   case Spades;
   const Tiles = self::Diamonds;
   const Clovers = self::Clubs;
   const Pikes = self::Spades;
}

// The constants and cases can be used interchangeably, since constants 
and cases are de-referenced with the same syntax
assert(Suit::Spades === Suit::Pikes);

I mean on mapping something to something else defined as a single assoc array constant.
Something like:

enum Role {
case User,
case Admin,
...
}

enum Action {
case Order_Edit,
case Order_Read,

private const BY_ROLE = [
Role::User => [self::Order_Read],
Role::Admin => [self::Order_Read, self::Order_Edit],
];

public function isAllowed(User $user) {
return in_array($this, self::BY_ROLE[$user->role]);
}
}

Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]

-- 

To unsubscribe, visit: https://www.php.net/unsub.php

Thanks a lot for this RFC, Larry and Iliya! I can't imagine the amount of
thought and work put into this.
Enums are definitely a most-wanted PHP feature.

I played a bit with the early implementation, and love it so far. Here are
my thoughts on the RFC and the current implementation:

Yay!

Serialization

I guess what it comes down to is whether / how easily a class can return

an existing instance when asked to unserialize, rather than setting
properties on an existing instance. That is, given the string
"C:4:Suit:6:{Spades}" can the class definition return the appropriate
singleton for Suits::Spades rather than a newly constructed object?

If this proves tricky to implement, it would probably be better to
forbid serialization than using the default object format and breaking
the singleton-ness of the case objects.

+1, totally agree with this statement. That's the first thing I tried when
playing with the implementation, and noticed that serialization is not
supported:

echo unserialize(serialize(Status::Active));
Notice: `unserialize()`: Error at offset 0 of 42 bytes

I would definitely expect strict equality to be maintained on enum cases
even after unserialization!

I've opened a task to just block serialization entirely for now. It's probably best to not support it at all than to have half-arsed buggy support, at least for now: https://github.com/Crell/enum-comparison/issues/46

var_export()

Currently, var_export() returns a __set_state() syntax:

var_export(Status::Active);
Foo\Bar\Status::Active::__set_state(array(
))

I guess this should just return Foo\Bar\Status::Active.

Good point. I've opened a task for that: https://github.com/Crell/enum-comparison/issues/47

Scalar Enums, ::cases()

The implementation does not support these yet, so I haven't had a chance to
play with them.
I share Pierre R.'s concerns, though:

Does this mean that an enum can't have two cases with the same primitive

value ? I would very much being able to do so, for example, when you
change a name and want to keep the legacy for backward compatibility.

But I'd understand if you just disallow duplicate scalar values altogether,
this is probably the most sensible solution here.
Another idea that comes to mind is that cases() could return an iterator
instead of an array, having the cases as keys and the scalars as values,
but this would probably come as a surprise and be bad for DX.

Off hand, I'm not sure if any languages support duplicate enums. I can see the use case for renaming, but I suspect it's going to just be too complicated to support in practice. I'll make a note in the RFC that they must be unique.

Enum & UnitEnum interfaces

The implementation does not seem to support these yet. Taking the examples
from the RFC:

Suit::Hearts instanceof Enum; // true => Parse error: syntax error,
unexpected token "enum"
Suit::Hearts instanceof UnitEnum; // true => FALSE

Yeah, we only added that to the RFC text an hour or three before you posted; Ilija has to catch up with the new text yet. :-) Please give him some time.

--Larry Garfield

Le 08/12/2020 à 18:40, Larry Garfield a écrit :

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
larry@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

• 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. :-(

Imo, this is good. This whole sub-classing part looked to me as too much
(at least for this step). Thank you for all this work.

--
Aleksander Machniak
Kolab Groupware Developer [https://kolab.org]
Roundcube Webmail Developer [https://roundcube.net]

PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

Am 08.12.20 um 18:40 schrieb Larry Garfield:

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 wonder whether this mechanism could be generalized to a serialization
mechanism that would allow e.g. Database Repositories to pull entities
from a database upon unserialization.

My example would something like this (simplified):

interface IdentifierBasedSerializable {
static function serializeToIdentifier(self $object) : string;
static function unserializeFromIdentifier(string $identifier) : self
}

class ExternallyStoredEntity implements IdentifierBasedSerializable {
static function serializeToIdentifier(self $object) : string {
return $object->id;
}

static function unserializeFromIdentifier(string $identifier): self{
    if (!\array_key_exists($identifier, self::$objectCache)) {
        self::$objectCache[$identifier] = new self($identifier);
    }
    return self::$objectCache[$identifier];
}

private static $objectCache = [];
public string $id;

public function __construct(string $id) { $this->id = $id; }

}

Until now it is not possible to unserialize an object to the canonical
instance created earlier in the program execution.
Serialization and subsequent unserialization breaks object identity
($a->id === $b->id <=> $a === $b) that is often desired when working
with objects that represent external entities. The list of allowed enum
values is in this regard a very simple database of identifiers.

I know that passing a complex serialization string to a static
unserialization factory method has the serious problem that circular
references can not be handled. But using only an identifier as the sole
contents of the serialization string avoids this problem entirely.

Greets
Dennis

Le 07/12/2020 à 16:26, Larry Garfield a écrit :

Thanks for taking the topic. I love it.

Regarding the ::cases() method on UnitEnum I guess it'd be more natural
to cast enum into an array like:

(array) Suit;

but I realize it'd be harder to implement. The question is if it was even
considered?

Regarding the ::from() method responsible for casting was a natural cast
operator considered instead?
For eg.
$suit = (Suit) $record['suit'];
Instead of:
$suit = Suit::from($record['suit']);

Cheers,
Michał Marcin Brzuchalski
We didn't really get into explicit casting, since it's so rarely used in conventional PHP code these days. I'm not sure off hand if supporting (Suit)"H" or (string)Suit::Hearts would be easy or hard. That would be an Ilija question.

Assuming it's feasible to do, what do people feel about supporting that? IMO, cases(), from(), and values() need to be kept no matter what as they're more self documenting and can be passed around as callables. So the question is just whether we should also try to add casting as an alias to those operations.

--Larry Garfield

Hello,

I deeply hate dark magic, and my motto is always "explicit is better".
So I'm NOT in favor of magic/explicit casting neither array-like syntax
on enums.

If it was only about me, I'd remove array syntax at all in PHP except
for real numerical-indexed static arrays in favor of explicit
list/hashmap/etc methods, but that's probably my Java past talking here :)

Regards,

Pierre

Assuming it's feasible to do, what do people feel about supporting that? IMO, cases(), from(), and values() need to be kept no matter what as they're more self documenting and can be passed around as callables. So the question is just whether we should also try to add casting as an alias to those operations.

From my experience answering questions about SimpleXML on Stack
Overflow, I can confirm that people find magic behaviour of (string)
hard to discover and understand, and it's not uncommon to see someone
write $foo->__toString() because they're more familiar with methods.

That's even more true for other casts, e.g. (int)$foo and (float)$foo,
which can be supported by built-in classes but not userland ones, so are
even less discoverable.

I can see the appeal of overloading cast syntax, but I would personally
be on the "just use explicit methods" side.

Regards,

--
Rowan Tommins (né Collins)
[IMSoP]

1. Will enum methods be idempotent?

If not, shouldn't they be?

Can you clarify what you mean here?

For a given parameter set the method would always return the same value. Note I am not suggesting that values would be fixed across different executions, only within a given execution.

Said another way, idempotent and deterministic[1] are effectively equivalent.

Taking this example the now() method would not be idempotent nor deterministic:

enum DayParts {
case Morning;
case Afternoon;
case Evening;
case Night;
public static function now() {
$now = intval(date('H',time()));
return match(true) {
$now < 8 => static::Night,
$now < 12 => static::Morning,
$now < 18 => static::Afternoon,
default => static::Evening,
};
}
}

[1] https://docs.microsoft.com/en-us/sql/relational-databases/user-defined-functions/deterministic-and-nondeterministic-functions

The only meaningful question I can think of is "can they change the object's state?" That's mostly answered in the RFC, most notably by specifying that enums may not have instance properties, to avoid them having any state to change.

Unless I'm missing something, trying to define "idempotence" or "pure functions" any more strictly than that would surely be a massive project in itself - for a start, you'd need a whitelist of all built-in operations which were side-effect free (i.e. no file writes, configuration changes, output, etc, etc).

I do not believe it should be a massive project. I believe it could be implemented with a simple map that takes a hash of the input parameters and maps to their return value. For idempotency this value should be calculated the first time the method is called.

After the first call every subsequent call would hash the input parameters, lookup the pre-calculated value from the map, and the just return it without re-executing any code in the method except for the return statement (I am considering of the desire to set a breakpoint in XDEBUG on return for all accesses, not just the first.)

The one potential concern is if the number of potential input permutations is large it could eat a lot of memory if the app actually used a lot of them. But then that is true on any use of memory in PHP, so if it became a problem for a developer I think it should be on them to rearchitect their solution to avoid using too much memory.

This is an important question to answer now because IF the answer to idempotency is "no" then restricting it a later to be idempotent would require accepting a BC break. But if the answer is YES, the restriction could always be relaxed in a future version if that ever made sense.

-Mike

5. Someone else mentioned shortcut syntax, which I would like to mention again, although I realize implement details might make this a non-starter.

So if I have a function that accepts a Size from above, e.g.:

function show(Size $size) {}

Then it would be great if we could call the function like this since its parameter was type-hinted:

show(::Medium)

Rather than always having to write:

show(Size::Medium)

So can we consider a shortcut syntax?

I'm not sure what value a shortcut syntax would bring, but it would surely break, or at least make ambiguous, union types:

function show(Enum1|Enum2 $value)  {}
show(::Medium)

Which enum would Medium resolve to?

Good question.

What could happen is:

1. It could resolve to the Enum that has a ::Medium,

2. Or it could be disallowed for union type hints (probably the better option as adding a "Medium" to the other enum could inadvertently break code that calls it.)

3. This suggestion could just be tabled.

Again, I am just asking if this is something we could consider because it would be nice to shorten line length in cases where expressions get really long.

Maybe a different question could be if a "use" statement could empower making explicit shorthands/aliases?

-Mike

P.S. I completely understand if either of these things are out of scope for this RFC.