On 21/05/2024 23:35, Larry Garfield wrote:
On Tue, May 21, 2024, at 5:30 PM, Bilge wrote:
Hi Internals,
I struggle to understand the benefit of "basic" enumerations and their
diminished API. In particular, I often find myself wanting to use
`from()/``tryFrom()` to convert a string to an enumeration. To do this,
I must convert it to a "backed" enum and copy & paste each name to its
value. In all other regards, I still want it to behave like a "basic"
enumeration, so I won't abuse the value of the names to act like a
mapping; the values will always mirror the names, and if I need to do
any mappings, I'll add match() functions.
My question, then, is why can't basic enumerations have these semantics
by default? Or, to state it more concretely, what would be the downside
to having all "basic" enumerations actually being "backed" enumerations
whose values implicitly mirror their names for the purposes of
converting to/from strings? Would this not make basic enumeration more
useful without any particular downsides?
Kind regards,
Bilge
Making enums not be "fancy strings" was a very deliberate decision. The RFC
covers that some. There's more information in our comparison research here:
https://github.com/Crell/enum-comparison
And I wrote an article about enum usage a while back here:
https://peakd.com/hive-168588/@crell/on-the-use-of-enums
--Larry Garfield
Hi Larry,
Thanks for the resources! Whilst I can appreciate this was a deliberate
design decision that did not come about by accident, I still didn't find
(skimming) anything that directly answers the question:
>What would be the downside to having all "basic" enumerations actually
being implicitly "backed" enumerations?
I gather from your (presumably derogatory) referencing of the same as
"fancy strings" that you would not approve such an implementation, but I
am struggling to understand why.
Cheers,
Bilge
P.S. Sorry for the (previously) incomplete subject line.
