Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118100
Message-ID: <78f26b4d-6f3e-f5e0-3ad5-3a2378ee7030@mabe.berlin>
Date: Mon, 27 Jun 2022 09:38:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.1
Content-Language: en-US
To: internals@lists.php.net
References: <CAPyj-LBQmoFEGZyMw3H5fAy-NwP3WdkH2ZviHWcBrhJ_8qrOGg@mail.gmail.com>
 <bb40be07-c3fc-4ca9-9365-37a50b8339cd@www.fastmail.com>
 <CAOWwgpmQC8ptMCn7JwV31nAzA3v76ERxM-XDi-+RQnfezAO1=g@mail.gmail.com>
 <6a016333-2be0-4865-b263-29611ecb4c62@www.fastmail.com>
In-Reply-To: <6a016333-2be0-4865-b263-29611ecb4c62@www.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][Under discussion] Fetch properties in const
 expressions
From: marc@mabe.berlin (Marc Bennewitz)


On 24.06.22 23:55, Larry Garfield wrote:
> On Fri, Jun 24, 2022, at 11:43 AM, Nicolas Grekas wrote:
>>>> Hi everyone
>>>>
>>>> I'd like to start a discussion on a simple RFC to allow fetching
>>>> properties in constant expressions.
>>>> https://wiki.php.net/rfc/fetch_property_in_const_expressions
>>>>
>>>> The RFC proposes adding support for fetching properties in constant
>>>> expressions using the -> operator. I'm looking forward to your
>>>> feedback.
>>>>
>>>> Regards,
>>>> Ilija
>>> The enum-in-attribute use case came up recently in Symfony.  I'm in favor
>>> and the RFC looks good to me.
>>>
>> Genuine question:
>>
>> In the thread about auto-implementing Stringable for string backed enums,
>> there is extensive argumentation to explain why ppl that use enums this way
>> are wrong. You mentioned writing a blog post about these reasons Larry, and
>> Benjamin (/cc) also expressed a similar opinion.
>>
>> So my question is: don't these arguments apply here also? Shouldn't we
>> reject this RFC and tell ppl to use consts instead? If not, why?
>>
>> Nicolas
> A fair question. :-)  (Also, I'm working on said blog post literally as we speak.)
>
> I'd say for many of the cases where the inability to use ->value has come up (eg, Attributes), a constant would indeed be the better solution.  That's what people should probably be doing there.
>
> However, while there are clear downsides to letting enums auto-coerce to strings (as discussed elsewhere), I don't really see a downside to this RFC.  An enum case's value or name properties are guaranteed constant and readonly, so there's no reason I can see to *not* allow them to be used in a constant, readonly context.  That it would allow someone to use SomeEnum::Beep->value in a place where it would probably be better to use SomeConst::Beep instead is a mostly-harmless side effect that doesn't violate any type expectations.  And, if anything, the slight clunkiness of the syntax serves as an indicator that maybe you are doing it wrong and should be looking at something else.
>
> So this patch is, in my mind, more about fleshing out a gap that fell through the cracks last version that happens to have a side effect of making connecting enums to pre-enum code possible, if a bit clunky.  Auto-converting enums to other types is violating the domain model of different types and confusing their type spaces in semi-magical ways.
>
> (Also, this is an understanding of the problem space I came to just in this past week, and hadn't fully chewed through when this RFC was first put forward.)

Last week I run into this limitation - just sharing in case you would 
see it a legitimate use case - not to say it can be done in another way:

I have defined classes for some public identifiers like `UserId`.
These identifiers should be prefixed which I have defined as constant.

Now as I have a lot of such classes and I want to make sure all of the 
prefixes are unique so I added an enum with all prefixes and use the 
enum value as constant value as well.

enum IdPrefix:string
{
     case USER_ID = 'u-';
     // ...
}

class UserId extends AbstractPrefixedUid
{
     public const PREFIX = IdPrefix::USER_ID->value;
}


Greetings,

Marc