On Sun, Dec 6, 2020 at 7:12 AM Rowan Tommins <rowan.coll...@gmail.com> wrote: > > 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?
Static variables don't emulate mutable state, they are mutable state. My question is why go out of the way to restrict things arbitrarily, particularly when the result is ineffective and just makes things suck more. It's irrelevant extra work to annoy people with no gain. > 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. Instance state being global is a well-known problem with singletons. Maybe don't use singletons then. Or simply document them as was done in the RFC. I'd prefer the former since singletons don't seem to buy much here but problems, though maybe I'm missing something. In any case why is static state being (kinda sorta) restricted along with it? > >> 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. Consistency. Which reduces both the wtf factor when working with them and edge cases for other features that interact with them. > > 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. Inconsistency is in no way a straw man. This RFC has enums being implemented as "fancy objects", based on classes, backed by objects, with the results being treated as classes and objects in every way except for.. well mostly a bunch of artificial restrictions that appear to have nothing to do with enums at all. > 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? No, that is a garbage standard that's been abused around here for too long. This RFC is proposing to introduce inconsistencies into the language, it's up to it to justify them. It is not up to me or anyone else to come along and pass your personal code review just to ask for that justification. > Restricting them will likely make other desirable features easier - for > instance, how would serialization work: Like serialization already works with objects, including singletons. > $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. Longer term plans are irrelevant except to avoid inadvertently shutting the door on something. This RFC is up for discussion, and will be up for voting, in isolation. It has to be able to stand on its own. > Regards, > > -- > Rowan Tommins (né Collins) > [IMSoP] > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
