On Mon, Jun 27, 2022 at 10:16 AM Rowan Tommins <rowan.coll...@gmail.com> wrote:
>
> On 27/06/2022 08:38, Marc Bennewitz wrote:
> > Now as I have a lot of such classes and I want to make sure all of the
> > prefixes are unique so I added an enum with all prefixes and use the
> > enum value as constant value as well.
> >
> > enum IdPrefix:string
> > {
> > case USER_ID = 'u-';
> > // ...
> > }
>
>
> This would never have occurred to me as a design, because I had no idea
> that the values of backed enums were enforced to be unique. I'm not sure
> if it can be considered "taking advantage of a side-effect", or if
> people always expected backed enums to be used that way.
>
> Ultimately, that's my reaction to both the enum-related RFC currently
> under discussion: I don't really understand what backed enums are
> intended for in the first place, so find it hard to judge whether
> expanding them in a particular way makes sense. If a string-backed enum
> can be considered just a unique set of strings, then it really has very
> little in common with how I think of (unbacked) enums, but maybe that's
> fine.
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
I think it is fair to consider backed enums a "set" vs. "enum." A good
use-case for integer-backed enums would be HTTP response codes,
however, the standard library only accepts integers
(http_response_code(), for example) and it would be nice if it either
accepted built-in enums or automatically cast integer-backed enums to
int. However, the latter probably makes more sense simply because
response codes are changing slightly, and will continue to evolve:
https://www.rfc-editor.org/rfc/rfc9110#section-15 (some 4xx codes have
been removed IIRC).
Robert Landers
Software Engineer
Utrecht NL
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
