Hi people!
Today I tried to do `ResourceType::from()` and was surprised that my IDE
immediately screamed at me. After further investigation, I realized that
Basic Enums (this is what the RFC called it [1]) does not have these
commodities backed into them.
I did some digging and I found 2 main discussions: Stringable by default
[2][3] and backed-in commodities [4]. I think Benjamin, Derick and Nicolas
have argued why Stringable by default may not be desirable and I only
mention this for completeness of the conversation. I don't want to talk
about that at all. Instead, I want to focus on the other side: construct
from string by default (from/tryFrom()).
I also read Larry's post that has been shared throughout these discussions
[5] and it seems fair and sound to use guardrails to discourage unintended
use. This gets into the territory of "let me do what I want, I know what
I'm doing" vs "let me limit what you can do because I built it and I know
exactly what it was intended for", which I also want to try and steer away
from debating, each camp has its merits.
Bilge said:
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?
While I'm searching for similar clarification, I want to pose the question
differently. I feel like the answer to his question is in Larry's article
about discouraging fancy strings. My question boils down purely to: *can
Basic Enums implement ::from() / tryFrom() methods?*
Larry said:
[...] In your case, you want to "upcast" a string to an enum. That means
you're doing some sort of deserialization, presumably. In that case, a
backed enum is what you want. *A unit enum isn't serializable, by design.*
Although this starts to thread into very pedantic territory, I think, in
fact, a *unit enum* (assuming it means Basic enum) is in fact always
serializable to a string: `$enum->value`. By design, the value is a string
and it cannot have duplicate values in a single enum. It means it's
extremely easy to define an Enum in PHP and at some point store it in a
storage engine / database in the form of `$enum->value`. Now if I want to
get back my Enum at a later stage I need to implement exactly the same code
that already exists in the PHP engine behind `Enum::from()`. Maybe it's not
serializable in the sense that it doesn't implement any true serialization
mechanism, which I'm guessing a backed-enum probably does, but I'm trying
to come from the very practical application of creating a Basic Enum at an
HTTP context (which is the bread and butter of PHP) and then recovering
said Enum in a background worker context without having to use PHP
`serialize()` function and store PHP-specific dialect in a database that is
used by multiple teams and programming languages.
I also take the point that it is easy to argue against all this: just put
`: string` on your Enum and duplicate the names with values. Still, this
doesn't address the "surprise effect" of "why this Enum doesn't have
::from() in it?". There doesn't exist any other value (string or otherwise)
that could be used in ::from() or ::tryFrom() in a Basic Enum, which could
make it less contentious. Also, in the spirit of NOT making Enums "Fancy
strings", I'm looking for ways to reconstruct my Enum and all the behaviors
available inside of it without even having to associate or think about a
string. The only reason a string comes into the discussion is because
$enum->value is one and is stored. I also checked and:
enum Foo {
case 1;
case 2;
}
is a parse error. [6].
Larry has also suggested that instead of making Basic Enum implement
`::from()` and `::tryFrom()` we could instead offer auto-populated
String-Backed Enum values. That means transforming this:
```
enum Foo: string {
case Bar;
case Baz;
}
```
(which is a Fatal Error today) into this:
enum Foo: string {
case Bar = 'Bar';
case Baz = 'Baz';
}
I also like this proposal. Although semantically, I think it would be
better / have been better to have Basic Enum implementing the ::from()
methods, one could argue that adding it now could be a breaking change
since people could have Basic Enum already implementing their own custom
::from() method.
In conclusion, the "complex" (as opposed to primitive) object Enum is not a
Fancy String and where I'm coming from I believe to be in sync with that
mindset. However, PHP is highly used in Web context where we may need to
use asynchronous processes to make API calls fast and schedule executions
at a different context which often involves serialization. As such, being
able to reconstruct a Basic Enum seems a rather fundamental need that we
can still make it viable by making a small `: string` change to the Enum
and opting-in into the from / tryFrom utilities. This should not affect
Int-Backed Enums at all.
Where casing is concerned (camelCase, PascalCase, snake-case, etc) [7], one
can argue that if you want to have full control over casing, you should
definitely take control over the values of your Enum. The beauty (in my
mind) about making it default to the enum name is that it doesn't matter if
I follow PER-CS rules or not, the truth is I don't need to think about
strings at all because my Enum is not a Fancy string.
I didn't intend to write such a long email, but I'm really keen on hearing
arguments against everything I shared to see if there are any flaws in my
thought process.
[1] https://wiki.php.net/rfc/enumerations#basic_enumerations
[2] https://externals.io/message/118040
[3] https://externals.io/message/124991
[4] https://externals.io/message/123388
[5] https://peakd.com/hive-168588/@crell/on-the-use-of-enums
[6] https://3v4l.org/cDISV#v8.4.10
[7] https://externals.io/message/123388#123394
--
Marco Deleu
