On Fri, Jan 29, 2021 at 7:17 PM Larry Garfield <la...@garfieldtech.com> wrote:
> On Mon, Dec 28, 2020, at 2:21 PM, Larry Garfield wrote: > > Hello, Internalians! > > > > After considerable discussion and effort, Ilija and I are ready to > > offer you round 2 on enumerations. This is in the spirit of the > > previous discussion, but based on that discussion a great deal has been > > reworked. The main change is that Enumeration Cases are now object > > instances of the Enumeration class rather than their own class. Most > > of the other changes are knock-on effects of that. > > > > Of particular note: > > > > * Cases may not have methods or constants on them. They're just dumb > values. > > * Enums themselves may have methods, static methods, or constants. > > * Traits are supported, as long as they don't have properties. > > * The value() method on scalar enums is now a property. > > > > The full RFC is here, and I recommend reading it again in full given > > how much was updated. > > > > https://wiki.php.net/rfc/enumerations > > > > The implementation is 98% complete; there's still a few lagging bits in > > reflection, and some opcache bugs that Ilija is still stomping on. > > > > There are a few outstanding questions listed that we would like > > feedback on. We're not entirely certain which direction to go with > > them, for reasons explained in the RFC. Input on those is especially > > welcome. > > > > Happy New Year. May it be enumerable. > > And we're back again. The RFC has been updated with a steady stream of > smaller improvements based on feedback and testing, and is now in its Final > Form(tm) (we think). The only major change worth noting is that we renamed > things. :-) > > An enum with no scalar backing is now called a Pure Enum, made up of Pure > Cases. One that does have backing values is called a Backed Enum, made up > of Backed Cases. That change is mainly to allow for future expansion to > non-scalar backing static values, should the use case arise. Reflection > was also reworked a bit to make it more logical. > > https://wiki.php.net/rfc/enumerations > > At this point, Ilija and I consider the RFC done and ready for a vote. > Baring any major issues being brought up, we plan to start the vote in the > first half of next week, probably Tuesday-ish. If you have any other bug > reports or tweaks, please speak now or forever hold your patches. > > --Larry Garfield > > Hi, Maybe IterableEnum can actually be just Enum. As you are not allowed to implement it and/or define it, wouldn't it work? That's how it's named internally in Java, not that it would matter but sometimes people forget it's just syntactic sugar there as well ( https://docs.oracle.com/javase/8/docs/api/java/lang/Enum.html): public abstract class Enum<E extends Enum<E>> implements Comparable<E>, Serializable. Also in the interface I think you can include the name property, similarly with how you did in BackedEnum interface. https://wiki.php.net/rfc/property_accessors will probably allow it to be clearly defined at some point. A bit it bothers me that backed enums are very easy to implement even without the special case and just a simple Enum would be fine. I mean even if you will have a backed enum, with would be simple and probably the need will come at some point to have also a public function getLegacyValue(): string and a public static function fromLegacyValue(string $value): Enum. But yes, using backed values is a common pattern so I'm guessing it's a valuable important use case. For storing in a database purpose, property name can be used directly, I think. It would nice to have in the rfc the recommended way to retrieve the Enum, given that you know the name. I'm guessing that would be Suit::$name; Thanks, Alex
