[IDEA] allow extending enum

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 :)!

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.

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:

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?

--

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.

Am Mi., 29. März 2023 um 12:49 Uhr schrieb Rokas Šleinius <raveren@gmail.com

:

Sidenote, just asking :) was this expected behaviour that I had to
analyse PHP source of the Docuwiki, create a new input field in
the registration form named "spam" and fill it to gain a wiki
username? Otherwise it would just keep expecting a different
answer from me no matter what email I put in...

No, thanks for reporting. This should be fixed now.

Best,
Niklas

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.

I was just about to write a response along the same lines. I think the
confusion comes because in Java-style OOP, the keyword "extends" actually
does two things at once:

1. Takes the existing definition and adds to or over-rides parts of it
2. Takes the existing type and declares a sub-type

What you actually want to do with an enum is:

1. Take the existing definition and add cases to it
2. Take the existing type and declare a super-type

To give a concrete example of why, consider Christian's hypothetical:

Imagine a Randomizer is much, much slower for certain boundaries and it
is decided that some programs do not care about Closed/Open but instead
care more about speed. So they would want to use something like
IntervalBoundary::Fastest.

If we use the normal definition of "extends", we could say this:

enum PerfIntervalBoundary extends IntervalBoundary {
case Fastest;
}

Now we have an enum with three cases, which is what we wanted. But we've
also declared a sub-type: we've said that "every PerfIntervalBoundary
is-a IntervalBoundary". That means that anywhere that previously expected
an IntervalBoundary, we can pass PerfIntervalBoundary::Fastest - but none
of the existing Randomizer classes will know what to do with it!

What we actually wanted to do is leave all the existing uses of
IntervalBoundary alone, but create a new WeirdPerfRandomizer which accepts
the new type. We wanted to list "PerfIntervalBoundary" as the input type,
but still be able to pass it IntervalBoundary::Closed.

In short, we want to say "every IntervalBoundary is-a PerfIntervalBoundary"

• the relationship is the other way around.

As George says, this can be implemented right now by using a union type
constraint, like PerfIntervalBoundary|IntervalBoundary, which means "allow
any case of PerfIntervalBoundary as well as any value of IntervalBoundary".

If we wanted to support it more directly, we would need a new keyword to
make clear that this is not a sub-type relationship - perhaps something
like "expands", "allows", or "encompasses".

Regards,

Rowan Tommins
[IMSoP]

Ok so I am trying to find the argumentation here:

This is by design.
The point of enums is to be limiting.

This is clearly an assumption. That statement is not in the docs or
RFC, nor such an oversimplification makes logical sense to me, but
maybe you have a source to back it up..?

Re: problem in the OP
You are approaching the design of this in a fundamentally wrong way.

The described problem is dealing with error codes not types, which
means that each error is assigned a new code. We are dealing with
anticipated errors here, things like validation, data integrity, 3rd
party API breakage etc.

e.g.: user gets code 456 trying to ship out package, it says package
not paid, user says he looked it up, its paid. The developer has a
very concrete lead to the problem - lookup usages of
ErrorCodes::Code_456.

The set in question is finite, as you say of course, but much larger
and different in principle than in the solution you are proposing.
Problem in OP is looking for a way for end users to keep adding new
domains to the error codes passed to the parent system to be handled.
The actual, real requirements are:

1. Ease of management of codes: simplicity of adding new codes to
   the set, easy lookup, simplicity of making sure a code is not used
   elsewhere before using it. All perfectly fulfilled by enums.
2. Reusing the parent system for different modules, using the parent
   system in two different packages I want to opensource. Open Sourcing
   the parent system..

Rowan Tommins is right on the target however, that is amazing feedback
for the desired functionality, excellent distillment of logic and all
correct points!

I will take some time to think about that.

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.

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:

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