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