Enum thoughts

gistfile1.txt

>  An Enumeration may have one or more case definitions, with no maximum, although at least one is required. 

Could an enum with no values potentially be useful? If not, should we still allow it for consistencies sake?

> __toString, Do we want this part or not? I only thought of it while writing this. I don't know if it's good or bad.

Could be useful. Why not.

> The Enum Type may also implement an interface, which all Cases must then fulfill, directly or indirectly. 

Still not sure if implementing methods per case is a good thing. Although if we allow type hinting the individual cases it's almost necessary. That also begs the question, can individual cases implement interfaces, use traits, etc?

>  [Ilija: We haven't discussed static methods at all. This is what makes the most sense to me at the moment but we can easily revisit this. I'm flexible.) 

Yeah, static methods per case make little sense to me.

> The Enum Type may also implement an interface, which all Cases must then fulfill, directly or indirectly. 

Right, this is also why $this->assocValue is almost necessary, as otherwise you have use pattern matching even though you already know the given type.

> case Kilometers(public int $num);

Is public here necessary? I get it is modeled after constructor property promotion but to private assoc values actually make sense? For example, how could you even pattern match when the value isn't available?

> In some languages, it is possible to enumerate all possible values of an Enum Type. For now that functionality is not implemented, but it may be in the future. It would be limited to the case where the Enum Type contains only Unit Values. (That limitation exists in other languages as well.)

Not sure if __toString has the same issue (do we want __toString to result in the same string for Option::Some with different values? probably not). I think this is useful enough to do right away :) We'd only synthesize this method (::allValues() or whatever) when all cases are unit cases.

Random thoughts:

What about properties per case? Could be useful for cases with associated values or for things like lazy getters.

The state matchine example is cool :)

Allowing each Case to implement its own methods is what makes the state machine example possible. Without that, that example becomes impossible. I like that capability.

The "Do we want this or not" was in reference to specifying Cases in Union types. I don't know if that's good, bad, or otherwise. __toString, yes, I want.

Currently property promotion relies on inlining the visibility. I figure for consistency we should do the same so it's obvious what you're doing. With them being read-only there's probably not that many cases for not making them public, but the Maybe example is one of them: You force access to it through a value() method to give None a way to intercept and reject it. I figure this is best left to the implementer to decide what fits their use case.

If you want to implement EnumType::values() now, I'm OK with it. I was trying to keep it MVP, but I'm not against including it.

Properties per case: I could see the argument here, but I am concerned about scope creep and increasing object-vs-enum confusion. It's something that is easier to add later than remove later. Right now there's a very clear and narrow concept of enum state that is similar to what other languages have, and if you need more than that, guess what, you need a real class. Blurring that line feels dangerous to me.