> On Dec 4, 2020, at 6:24 PM, Larry Garfield <la...@garfieldtech.com> wrote:
>
> Greetings, denizens of Internals!
>
> Ilija Tovilo and I have been working for the last few months on adding
> support for enumerations and algebraic data types to PHP. This is a
> not-small task, so we've broken it up into several stages. The first stage,
> unit enumerations, are just about ready for public review and discussion.
>
> The overarching plan (for context, NOT the thing to comment on right now) is
> here: https://wiki.php.net/rfc/adts
>
> The first step, for unit enumerations, is here:
>
> https://wiki.php.net/rfc/enumerations
Great work.
>
> There's still a few bits we're sorting out and the implementation is mostly
> done, but not 100% complete. Still, it's far enough along to start a
> discussion on and get broader feedback on the outstanding nits.
1. Will enum methods be idempotent?
If not, shouldn't they be?
---------
2. Will enum cases be able to have attributes applied given the change in
implementation?
---------
3. "Cases are not intrinsically backed by a scalar value."
Completely agree with not using an ordinal value. It is too easy to change an
ordinal value and break some hidden dependency.
However, I would ask we consider a default string value, i.e. that this:
enum Size {
case Small;
case Medium;
case Large;
}
Would be equivalent to:
enum Size {
case Small = 'Small';
case Medium = 'Medium';
case Large = 'Large';
}
The justification is for use-cases with a large number of cases it would be too
easy to have typos and/or copy-paste errors if the developer has to explicitly
specify the value.
Also, the following would leave the values of Medium and Large undefined given
that enumerations supports only a single type at a time:
enum Size {
case Small = 1;
case Medium;
case Large;
}
So, can enums get a default value of their name as a string when zero values
are provided?
---------
4. "Class/Enum inheritance. - Enums are by design a closed list"
I would ask if this is really necessary to disable inheritance?
Consider the following as a example where I use a known list for clarity but
where I am really more interested is lists a developer maintains, i.e. their
own apps list of errors:
enum OsErrors {
case EPERM = 1;
case EINTR = 4;
case EIO = 5;
case ENXIO = 6;
case E2BIG = 7;
....
}
enum FileErrors extends OsErrors {
case ENOENT = 2;
case ENOEXEC = 8;
case EBADF = 9;
....
}
enum ProcessErrors extends OsErrors {
case ESRCH = 3;
case ECHILD = 10;
....
}
Without inheritance a developer could not create a new error enum, such as
SpeachRecognitionErrors and be able to include the base errors without having
to duplicate them.
Now it is very possible that someone can focus on my example and explain why
enums are not the right solution here, but please do not to that.
Instead please consider without inheritance nobody would be able to reuse a
base set of enums w/o duplication of names and/or values.
So can we revisit the idea of disallowing inheritance?
---------
5. Someone else mentioned shortcut syntax, which I would like to mention again,
although I realize implement details might make this a non-starter.
So if I have a function that accepts a Size from above, e.g.:
function show(Size $size) {}
Then it would be great if we could call the function like this since its
parameter was type-hinted:
show(::Medium)
Rather than always having to write:
show(Size::Medium)
So can we consider a shortcut syntax?
---------
> I should note that while the design has been collaborative, credit for the
> implementation goes entirely to Ilija. Blame for any typos in the RFC itself
> go entirely to me.
>
> *dons flame-retardant suit*
>
> --
> Larry Garfield
> la...@garfieldtech.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
Again, great work!
-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
