Hi Larry, pon., 28 gru 2020 o 21:22 Larry Garfield <la...@garfieldtech.com> napisał(a):
> 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. > I really like the shape of the current RFC. I'd like to ask a few things: 1. Regarding the Scalar Enums since scalar values need to be literal and by design they're read only why they use a spear "->value" on enumeration? A spear "->" in objects is dedicated to class properties and by default they make thinking of property which in most cases is read-write visible. An example using Suit enumeration from RFC: // when I assign an enumeration to variable $var = Suit::Spades; // then reaching it's value using "->value" echo $var->value; // 'C' // Looks just like an object property fetch By default if a property is visible it is write accessible as well, which may confuse. Instead of using spear "->value" would it be possible to fetch the value just like object constants? print Suit::Clubs::value; // 'C' echo $var::value; // 'C' This mentally indicates by default that it's value is constant, simple scalar value and read only! 2. Regarding the Scalar Enums declaration syntax enum Suit: string { case Hearts = 'H'; } Would it make sense to move the part declaring enumeration value before enum name? I think it was put here to look similar to function return type, but IMHO it looks better and reads easier when moved before enum name: enum:string Suit { case Hearts = 'H'; } Leaving the space between enum name and bracket for further extensions in future. What do you think? Cheers, Michał Marcin Brzuchalski
