On 22/05/2024 00:31, Larry Garfield wrote:
I could see an argument for auto-populating the backing value off the enum name
if it's not specified, something like this:
enum Options: string {
case First; // This implicitly gets "First"
case Second = '2nd';
}
This reminds me of the short-hand key-value syntax that JavaScript
allows, and people have occasionally requested equivalents for in PHP,
where { foo } is equivalent to { 'foo': foo }
The downside I see to all such short-hands is that they make it much
harder to refactor safely, because the identifier and the string value
are tied together.
For instance, maybe you want to rename Options::First to Options::Legacy
and Options::Second to Options::Modern so you edit the enum, and find
all references in code:
enum Options: string {
case Legacy;
case Modern = '2nd';
}
But now everywhere you've serialized the old value of "First" is going
to break, because the first case now has the implicit backing value of
"Legacy" instead!
To avoid this, you have to go ahead and specify all the backing values:
enum Options: string {
case Legacy = 'First';
case Modern = '2nd';
}
Having to specify both the name and value in the first place makes that
decision much more obvious, for what seems to me to be very little
up-front cost.
Regards,
--
Rowan Tommins
[IMSoP]
