Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118063
MIME-Version: 1.0
References: <CAOWwgpmG33Ybp6KS4ePrMgMJdW5xX+M2mos2cpgoVNUy8dVMjQ@mail.gmail.com>
 <9C11261B-B9D0-4342-81EB-60276B3036E5@php.net> <2cee17c0-7b77-4709-94b9-598a4c3d1f49@www.fastmail.com>
In-Reply-To: <2cee17c0-7b77-4709-94b9-598a4c3d1f49@www.fastmail.com>
Date: Wed, 22 Jun 2022 22:31:22 +0300
Message-ID: <CAAwdEzDJf9g2Zo5tgTz3+2+RgwM=e+=JFdWOrXu0TxFDyo7Fyw@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ce9ba105e20e62a4"
Subject: Re: [PHP-DEV] [RFC] [Under Discussion] Auto-implement Stringable for
 string backed enums
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--000000000000ce9ba105e20e62a4
Content-Type: text/plain; charset="UTF-8"

On Wed, Jun 22, 2022 at 8:27 PM Larry Garfield <larry@garfieldtech.com>
wrote:

>
> So I am firmly against making it easier to (mis)use enums in a situation
> where constants are already the superior solution by every metric.  The
> only argument I see is making case 1, transitioning from a string to an
> enum for a genuinely limited-case, easier.  But in that case, the
> transition is going to have to happen eventually anyway, and that means the
> type is going to change at some point, and the same BC issue will appear,
> just at a different time.  Unless the intent is to then never change the
> type and keep the function incorrectly typed (from the POV that it's
> logically an enum, even though string typed was the best/correct type for
> years) forever, in which case... use a set of constants.
>
>

Hi!
I'm with you on what you mentioned here.

But also, I think the need I understood arises from another case that is
neither 1 or 2.
When you have two domains the value might need to be represented as a
backed enum in one side and as a string in the other.
As far as I understood, this is the case, with applications that are in one
domain wants to have a proper enum for let's say the app roles as the
possible roles are just a limited set.
That application is using another library to configure the ACL using those
roles and this is another domain that does not have a limited value on the
role representation, it's just a string.
Naturally, you should just transform the enum instance to the string and
that should be done using the value property. But this does not work for
configurations done through attribute parameters.
And I think this is the only problem we should fix and that's fixable by
https://wiki.php.net/rfc/fetch_property_in_const_expressions

What you mentioned about developers using enum in the wrong way is
completely true and it's been a long effort for me in explaining this.
I was hoping it would be diminished somehow by increased popularity of
enums, now that they are supported by everyone. But the usages are also
increasing.

Regards,
Alex

--000000000000ce9ba105e20e62a4--