Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119768
MIME-Version: 1.0
References: <CAF-mU4yTkfERD8zDW7HHxXBEevOnaa_OEPuEAJvJ9L38XA9d6w@mail.gmail.com>
In-Reply-To: <CAF-mU4yTkfERD8zDW7HHxXBEevOnaa_OEPuEAJvJ9L38XA9d6w@mail.gmail.com>
Date: Wed, 29 Mar 2023 13:30:06 +0100
Message-ID: <CAFPFaMJ8kQYuH-zAvEeCwK-QLppqsdF5sSsOGUMPr99kh8yewg@mail.gmail.com>
To: =?UTF-8?Q?Rokas_=C5=A0leinius?= <raveren@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000079748d05f809233b"
Subject: Re: [PHP-DEV] [IDEA] allow extending enum
From: george.banyard@gmail.com ("G. P. B.")

--00000000000079748d05f809233b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 29 Mar 2023 at 09:31, 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 extend
> anything else.
>

This is by design.
Enumerations are in type theory parlance sum types.
Objects in PHP, in general, are what are called product types.


> From a user perspective it's surprising - and actually limiting.
>

The point of enums is to be 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.
>

You are approaching the design of this in a fundamentally wrong way.
Enums, as sum types, are meant to enclose a *finite* number of states.
If you want to expand those finite number of states, the solution is to use
a union type.

Let's say you have those 3 enums:

enum GenericErrors {
    case ErrorType1;
    case ErrorType2;
}

enum FileErrors {
    case FileErrorType1;
    case FileErrorType2;
    case FileErrorType3;
}

enum NetworkErrors {
    case NetworkErrorType1;
    case NetworkErrorType2;
    case NetworkErrorType3;
}

And you have a function that can fail with either a generic error or a file
error then you can be explicit by having:

function foo(): T|GenericErrors|FileErrors { /* Do something or Fail */ }

This signature provides you with great type safety and can be checked via
static analysis that *all* error cases are handled.
Moreover, you know you don't need to handle NetworkErrors.
Extending an Enum *loses* you this type safety, because now ff you say
something returns a GenericErrors well who knows if you cover all cases
because someone might have ad-hock added a new one.

PHP's type system is not perfect yet, but it has become powerful enough
that you can do things like what I just described.
Ideally we would have generics, and you could use a Result/Either Monad
(fancy word for "wrapper") to have a return type of Result<T,
GenericErrors|FileErrors>

Use the type system properly instead of trying to shove everything into an
"Inheritance" view of things.
Union types are not "bad", they are another way of creating a sum type.
(You could, with a lot of effort, create "proper" enumerations since PHP
8.0 by using union types and singleton classes.)


PROPOSAL:
>
> Enums should be able to extend other enums.
>
> For a complete wishlist, add:
>  * abstract enums;
>
 * enums allowed to implement interfaces;
>

Enums can already implement interfaces: https://3v4l.org/tKtQ0


> 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?
>

I dear hope so not.
Breaking fundamental type theoretical assumptions is terrible.

Best regards,

George P. Banyard

--00000000000079748d05f809233b--