Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113587
MIME-Version: 1.0
References: <2ff5377c-3718-feb1-ba20-96df47357414@mabe.berlin>
 <CAPyj-LCZwon475=8RKjoDabosznGanDw1dtcvh9=Ofbm5ycyoQ@mail.gmail.com> <9f234d2a-7875-2871-6726-e7b8175099f3@mabe.berlin>
In-Reply-To: <9f234d2a-7875-2871-6726-e7b8175099f3@mabe.berlin>
Date: Wed, 17 Mar 2021 09:36:44 +0100
Message-ID: <CAPyj-LCKyw41Gre4YJ7=6zu9ZssvcooKT=KdPkMg7-c=aEAh9A@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Inconsistency in enumerations RFC
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Marc

> >> I think it would
> >> be much clearer if there would be two different interfaces like:
> >> ``` interface IntEnum extends UnitEnum { public int $value; public
> >> static function from(int$value): static; public static function
> >> tryFrom(int$value): ?static; }
> >> interface StringEnum extends UnitEnum { public string $value; public
> >> static function from(string $value): static; public static function
> >> tryFrom(string $value): ?static; } ``` or else the above example should
> >> return a NULL or even case matching the string representation instead of
> >> TypeError as it matches the defined argument types.
> > I guess the interface would be more accurate. I'm not sure if that's a
> > huge win or just unnecessarily bloats the API. I think using
> > BackedEnum as a type hint should be relatively rare in practice.
> > Optimally we could add an associated type or generic type to
> > BackedEnum but that's currently not possible.
>
>
> I think it would be at least be helpful for example on mapping an
> enumeration from database to PHP as it's possible with doctrine types
> and probably also for static analyzers without the need to special case
> enumeration objects.

Can you provide a concrete example where the current interface is
inadequate? I can't imagine a situation where you'd want to accept all
integer BackedEnums but string BackedEnums. If we ever expand the
types that backed enums accept the number of interfaces will grow
linearly.

> I also don't think one additional interface bloats up the API or waiting
> for generics helps as nobody knows if this will ever be a thing in PHP.
>
> Would this actually require a follow-up RFC or could this be done as a
> small implementation detail change ?

Historically, things like this have been done before if nobody
objects. But that seems unjustified at this point given the lack of
concrete reasoning.

Ilija