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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
