Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119762
MIME-Version: 1.0
References: <CAF-mU4yTkfERD8zDW7HHxXBEevOnaa_OEPuEAJvJ9L38XA9d6w@mail.gmail.com>
 <CAPzBOBPDmiMs6hcYANh7pUVUHGJqyPK6vGvo4dgPFtYftTW67w@mail.gmail.com>
 <CAF-mU4xDj1oWx3RjnW+gQOxoVeiTx_dYkU_7xwgxE3cu0fvsRQ@mail.gmail.com> <CADyq6sJz=Ex6SS6wgOw20Lh8KV_JPhx_eYTCX=kY0eKCQXUhwQ@mail.gmail.com>
In-Reply-To: <CADyq6sJz=Ex6SS6wgOw20Lh8KV_JPhx_eYTCX=kY0eKCQXUhwQ@mail.gmail.com>
Date: Wed, 29 Mar 2023 12:31:14 +0300
Message-ID: <CAF-mU4wKZ+Zx9Qu3CYEF2GYakop+c0z4sot_3663w3nGb1bxOA@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: Robert Landers <landers.robert@gmail.com>, internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [IDEA] allow extending enum
From: raveren@gmail.com (=?UTF-8?Q?Rokas_=C5=A0leinius?=)

> BC break
Hm, do you really think so? I wouldn't say removing the final
attribute from enums
actually "breaks" any functionality.

It WOULD allow some potentially illicit hacking to the end users of
our code, that's
true. I'd say a minor possibility of impact.

And anyway, isn't that what got you to fall in love with PHP in the first p=
lace?
Some good ol' illicit hacking of some dude's library :)


On Wed, 29 Mar 2023 at 12:22, Marco Pivetta <ocramius@gmail.com> wrote:
>
> 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 `f=
inal` 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 im=
plicit 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> wro=
te:
>>
>> > 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 illustrate=
d 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@=
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 e=
xtend
>> > > 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
>>