> to restrict options within a certain range.
Okay that's an aspect of enums that I never gave much thought to, but
you're completely right.
However to be explicit about that aspect of functionality one would
then have to also be
allowed to define final enums.
That way you still have both options - to restrict the option set, but
to also allow adding
custom ones while benefiting from other enum advantages.
Thus, rfc idea seems to be:
* enums should be able to extend other enums;
* abstract enums;
* enums allowed to implement interfaces;
* final enums (NEW!)
> BackedEnum&MyCustomBehaviorInt
That's a fascinating approach but to a different problem than illustrated in OP.
Would you mind sharing (in private preferably to not distract from the
discussion) the
gist of the problem this solves? I'm really curious, as I've yet to
use intersect types :)!
On Wed, 29 Mar 2023 at 11:47, Robert Landers <landers.rob...@gmail.com> wrote:
>
> On Wed, Mar 29, 2023 at 10:31 AM Rokas Šleinius <rave...@gmail.com> wrote:
> >
> > Enums were a very useful addition to PHP, however one aspect of them is
> > neither
> > explicitly documented - or seemingly even talked about.
> >
> > Enums were implemented as final so they cannot be extended nor can extend
> > anything else.
> >
> > From a user perspective it's surprising - and actually limiting.
> >
> > USAGE EXAMPLE:
> > I am making an error management system: each error presented to the user
> > must have a unique code visible.
> >
> > ```php
> > class SystemError
> > {
> > public function __construct(
> > private string $errorText,
> > private ErrorCode $code
> > ) {
> > }
> >
> > public function __toString():
> > {
> > return $this->errorText . ' ' . $this->code->toString();
> > }
> > }
> > // ...
> >
> > enum ErrorCode
> > {
> > case Code_1;
> > case Code_2;
> >
> > public function toString(): string
> > {
> > return 'Error code:' . substr($this->name, strlen('Code_'));
> > }
> > }
> > ```
> >
> > Now I want to modify it to support different modules with different
> > namespaces for
> > errors, e.g. an ApiError, simple enough:
> >
> > ```php
> > enum BaseErrorCode
> > {
> > // ...
> > }
> >
> > enum ErrorCode extends BaseErrorCode
> > {
> > case Code_1;
> > case Code_2;
> >
> > // ...
> > }
> >
> > enum ApiErrorCode extends BaseErrorCode {
> > // ...
> > function toString(): string
> > {
> > return 'Error code:API-' . substr($this->name, strlen('Code_'));
> > }
> > }
> > ```
> >
> > This results in a syntax error.
> >
> > PROPOSAL:
> >
> > Enums should be able to extend other enums.
> >
> > For a complete wishlist, add:
> > * abstract enums;
> > * enums allowed to implement interfaces;
> >
> > However since I have no experience in PHP source code, I can only
> > provide the test suite for a possible PR this might have :(
> >
> > Do you think this is likely to get implemented?
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
>
> Hey Rokas,
>
> My approach has been to use an intersection type like:
> BackedEnum&MyCustomBehaviorInterface
>
> This works for me but it'd be interesting if something like that
> wouldn't work for you.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
