Re: [RFC] Enumerations, Round 2
| From: | Larry Garfield | Date: | Mon, 04 Jan 2021 03:25:31 +0000 |
| Subject: | Re: [RFC] Enumerations, Round 2 | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-112742@lists.php.net to get a copy of this message | ||
On Sun, Jan 3, 2021, at 2:25 PM, Marc wrote:
> >> You already provide a lookup mechanism with
> >>
MyEnum::from() - I don't
> >> see a real use-case for proving a pre build map. The main use case I see
> >> is to list all possible enum values but this doesn't require a map and a
> >> zero-indexed-array would also be more performant with packed arrays
> >> (correct me if I'm wrong).
> > I do somewhat agree with you there. We're essentially returning
> > Array<UnitEnum>|Map<int|string, ScalarEnum>
> > which feels
> > inconsistent. When you're calling cases() you're most likely going to
> > loop over it at which point $case->value is available at your
> > disposal.
>
> Would you consider making cases() returning a simple list in
> all cases
> instead of differentiate between UnitEnum and ScalarEnum given the fact
> that mostly people just want to loop over cases and a lookup is already
> available with ScalarEnum::from() to provide a cleaner interface?
>
> Marc
Ilija and I talked this one over a bit more, and decided that you're right. Between ->value
and from() we couldn't come up with a use case that would need the assoc array that
wouldn't work just as well with ->value, and it makes the method type definition simpler.
I've updated the RFC to have cases() always return a packed array; Ilija will update the PR
soon.
Thanks for your feedback!
--Larry Garfield