Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119761
MIME-Version: 1.0
References: <CAF-mU4yTkfERD8zDW7HHxXBEevOnaa_OEPuEAJvJ9L38XA9d6w@mail.gmail.com>
 <CAPzBOBPDmiMs6hcYANh7pUVUHGJqyPK6vGvo4dgPFtYftTW67w@mail.gmail.com> <CAF-mU4xDj1oWx3RjnW+gQOxoVeiTx_dYkU_7xwgxE3cu0fvsRQ@mail.gmail.com>
In-Reply-To: <CAF-mU4xDj1oWx3RjnW+gQOxoVeiTx_dYkU_7xwgxE3cu0fvsRQ@mail.gmail.com>
Date: Wed, 29 Mar 2023 11:22:41 +0200
Message-ID: <CADyq6sJz=Ex6SS6wgOw20Lh8KV_JPhx_eYTCX=kY0eKCQXUhwQ@mail.gmail.com>
To: =?UTF-8?Q?Rokas_=C5=A0leinius?= <raveren@gmail.com>
Cc: Robert Landers <landers.robert@gmail.com>, internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000003b380b05f80685e9"
Subject: Re: [PHP-DEV] [IDEA] allow extending enum
From: ocramius@gmail.com (Marco Pivetta)

--0000000000003b380b05f80685e9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey Rokas,

The idea of declaring an enum `abstract` is potentially worth exploring
(I'm not convinced, but go for it), but beware that removing the implicit
`final` from ENUMs is a BC break, since it breaks the assumption that an
ENUM is a sealed type.

If you design a proposal now, you need to consider that `final` as the
implicit default is an existing contract that really enables ENUM usage.

Marco Pivetta

https://mastodon.social/@ocramius

https://ocramius.github.io/


On Wed, 29 Mar 2023 at 11:05, Rokas =C5=A0leinius <raveren@gmail.com> wrote=
:

> > 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.robert@gmail.com>
> wrote:
> >
> > On Wed, Mar 29, 2023 at 10:31=E2=80=AFAM Rokas =C5=A0leinius <raveren@g=
mail.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
>
>

--0000000000003b380b05f80685e9--