Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118074
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-713-g1f035dc716-fm-20220617.001-g1f035dc7
Mime-Version: 1.0
Message-ID: <8a60d091-a7fc-4ba9-bbf0-82644c537910@www.fastmail.com>
In-Reply-To: 
 <CAAwdEzDJf9g2Zo5tgTz3+2+RgwM=e+=JFdWOrXu0TxFDyo7Fyw@mail.gmail.com>
References: 
 <CAOWwgpmG33Ybp6KS4ePrMgMJdW5xX+M2mos2cpgoVNUy8dVMjQ@mail.gmail.com>
 <9C11261B-B9D0-4342-81EB-60276B3036E5@php.net>
 <2cee17c0-7b77-4709-94b9-598a4c3d1f49@www.fastmail.com>
 <CAAwdEzDJf9g2Zo5tgTz3+2+RgwM=e+=JFdWOrXu0TxFDyo7Fyw@mail.gmail.com>
Date: Thu, 23 Jun 2022 10:32:22 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] [Under Discussion] Auto-implement Stringable for string
 backed enums
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Jun 22, 2022, at 2:31 PM, Alexandru P=C4=83tr=C4=83nescu wrote:
> 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 situat=
ion
>> where constants are already the superior solution by every metric.  T=
he
>> 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 mea=
ns the
>> type is going to change at some point, and the same BC issue will app=
ear,
>> 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 i=
n 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 t=
hose
> 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 a=
nd
> that should be done using the value property. But this does not work f=
or
> 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

Yes, I'm planing to vote +1 on that RFC.  Although in that case, the sam=
e logic for why to use a constant instead still applies.

> 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

I may need to publish a blog post on this issue specifically that Symfon=
y and others can point to when people keep asking them to do the wrong t=
hing.  I fully understand that major frameworks and libraries (Symfony e=
t al) are getting the pushback of people trying to do the wrong thing, b=
ut the solution should be better educational efforts so people stop tryi=
ng to do the wrong thing, not making it easier to do the wrong thing.

--Larry Garfield