Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119776
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-238-g746678b8b6-fm-20230329.001-g746678b8
Mime-Version: 1.0
Message-ID: <d96e9330-ed68-42ca-b713-0e256027a5cd@app.fastmail.com>
In-Reply-To: 
 <CAF-mU4wUiN3sOLkif1tTAorv08=5rrQT3SEQ2qxVfCNXnKMaHg@mail.gmail.com>
References: 
 <CAF-mU4yTkfERD8zDW7HHxXBEevOnaa_OEPuEAJvJ9L38XA9d6w@mail.gmail.com>
 <CAFPFaMJ8kQYuH-zAvEeCwK-QLppqsdF5sSsOGUMPr99kh8yewg@mail.gmail.com>
 <CAF-mU4z2+seOrgY7vza3i0NGif5nM9SSJKqp-K3_CSyzvicLYg@mail.gmail.com>
 <CALKiJKqR4sxKWMX=3a5VFwnZKzBOY6k5w8kXPB0BKojdzJLqZw@mail.gmail.com>
 <CAF-mU4wUiN3sOLkif1tTAorv08=5rrQT3SEQ2qxVfCNXnKMaHg@mail.gmail.com>
Date: Wed, 29 Mar 2023 15:39:31 +0000
To: "php internals" <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: larry@garfieldtech.com ("Larry Garfield")

On Wed, Mar 29, 2023, at 2:25 PM, Rokas =C5=A0leinius wrote:
> First, I'm pretty sure I agree now that enums should *not* be
> `extend`-ed as regular classes, there's a fundamental difference as
> you state - the extended enum is a fundamentally different THING as it
> can hold different values - when an enum's sole purpose is to hold one
> of the set of values.
>
> That is to say - for most implementations that's the desired case.
>
> I'll refer to the solution to the OP problem as ECS, Error Code System.
>
> For ECS, the most elegant, but also the only, solution I can come up
> with - is the kind of enum that you also suggest, a `base-enum`.
> `abstract enum`?
>
> Let me try again to describe the problem that I came here with that is
> unsolvable by union types:
>
> 1. ECS is a *generic* component. I want to plug it into any working
> system (like an existing cms).
> 2. Invoking it must provide a unique ErrorCode. The existing cms has
> to create an enum that will be accepted as `type: ErrorCode`. It
> cannot edit the existing ErrorCode as it is part of ECS and not the
> cms.
> 3. There is NO special handling for the custom ErrorCode's that the
> users of ECS create. We are just using the enums inferred value.
>
> I will keep processing this situation further, but for now it seems to=
 me like
>
> 1. Extending enums is fundamentally flawed.
> 2. Basing enums off of other enums has valid usage scenarios.
>
> In that case, and, again, this needs way more thought to it, it's not
> such a "generic way forward" that seemed to me at first and might only
> provide marginal value at the cost of type complexity and that is most
> probably, unfortunately, not worth it...
>
> (unless `abstract enum` might make sense, but my brain needs some time
> off of this problem for now)
>
> Thank you for such a thought out discussion, everyone!

1) Please don't top-post.

2) Some good reading material for this topic, both on enums and on error=
 handling:

https://peakd.com/hive-168588/@crell/on-the-use-of-enums
https://peakd.com/hive-168588/@crell/much-ado-about-null

They're not short, but that's because they are complete. :-)

3) In the error code case, the answer is to leverage the fact that enums=
 *do* support interfaces.

interface ErrorCode
{
  public function message(): string;
}

enum CommonErrors: string implements ErrorCode
{
  case YourFault =3D 'You screwed up';
  case OurFault =3D 'We screwed up';

  public function message(): string
  {
    return $this->value;
  }
}

readonly class SomeoneElseError implements ErrorCode
{
  public function __construct(privateUser $atFault) {}

  public function message(): string
  {
    return sprintf('%s screwed up', $this->atFault->name());
  }
}

Now an error handling system can type against the ErrorCode interface, c=
ommon errors have trivially simple enum values you can use, but you can =
also make your own.  In this case, you're *not* using an enum as a limit=
ed-set; you're taking advantage of it being a way to predefine singleton=
 objects.  I would consider this a completely valid use of enums, and ac=
tually do something very similar in my serialization library:

https://github.com/Crell/Serde/blob/master/src/Renaming/RenamingStrategy=
.php
https://github.com/Crell/Serde/blob/master/src/Renaming/Cases.php
https://github.com/Crell/Serde/blob/master/src/Renaming/Prefix.php

4) As others have said, extending enums is a bad idea with lots of reaso=
ns it's a bad idea, both conceptual and pragmatic.  However, I would be =
open to discussing a `use` for enums to import cases from one enum into =
another. =20

There's two concerns with that to consider:

A) What happens to methods on the imported enum?  Are they pulled in as =
well?  Do interface definitions carry over?  I don't know.

B) The long-term goal is to expand Enums to include associated values (h=
ttps://wiki.php.net/rfc/tagged_unions, although that's a bit out of date=
 now so don't take it as a roadmap).  How would `use`-ing an enum within=
 another enum affect that?  I have no idea, off hand.

--Larry Garfield