On 06/12/2020 00:17, Paul Crovella wrote:
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.
I'm not sure what you mean here, but it sounds a bit like you're saying
there are ways to emulate mutable state, so why bother restricting it?
The point is that since enum cases are singleton objects, any instance
state would actually be global across the program, which is probably not
what people would expect.
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?
On a singleton object, instance methods and late static binding are
equivalent, but instance methods are probably more intuitive, since
people are more used to writing code like "$this->suit->shape();" than
"$this->suit::shape();"
I guess both could be supported, but other than more code style
decisions to make, I can't think of what they'd add.
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?
"Inconsistency" is a straw man here, because these are a brand new
concept that already does things objects don't do. So let's flip it
around: do you have any use cases for directly storing state on an enum
case, remembering that such state would be unavoidably global?
Restricting them will likely make other desirable features easier - for
instance, how would serialization work:
$a = Suit::Hearts;
$a->setColour(Colour::Pink);
$serialized = serialize($a); // does this serialize the instance state?
$a->setColour(Colour::Purple);
$b = unserialize($serialized);
assert($a === $b); // as discussed elsewhere, this should be true
assert($a->getColour() === $b->getColour()); // are they both pink?
both purple?
Note that Larry's longer term plan is for "algebraic data types",
including "tagged unions": https://wiki.php.net/rfc/adts Unlike
straight-forward enum cases, these are not singletons, and each instance
has its own associated state.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
