On 13 May 2023 10:04:39 BST, Lydia de Jongh <flexj...@gmail.com> wrote:
>I prefer a magic constant like `::name` instead of a function call as it >can be used in a wider scope; for example as a parameter in an Attribute. Don't confuse the syntax with the implementation: "::class" isn't actually a constant, and the proposed "nameof()" isn't actually a function; both are just syntaxes understood by the compiler to generate strings according to certain rules. The RFC explicitly mentions use in attributes: > The nameof() function is not necessarily a function in the traditional sense > and can be used anywhere a string literal can be used (such as to define > static constants, array keys, and attributes). I'm lukewarm on the RFC myself - I can't think of many places I'd use it, and some of the use cases feel like they would ideally not involve strings at all. But I can't actually think of a good reason *not* to include it. The one part of the RFC that surprised me was this: > When getting the name of constants and functions, the name will NOT be the > full name, but the lexical name. This means that if the name is use'd, it > will be that name. However, if the full name is used in the nameof(), the > full name is returned. No reason is given *why* it works this way, and expanding the namespaces on a name is one of the most useful features of "::class". Importantly, it means that the string created can be passed to other contexts, and still refer to the same thing. For instance: use function Acme\bar as foo; ... #[SomeAttribute(callback: nameof(foo(...))] ... The attribute constructor, defined in a different file, can't do anything useful with the string 'foo'; it needs to know the qualified name of the function the user referenced, 'Acme\bar'. Similarly, I'm not wholly clear why nameof(MyClass::method(...)) should evaluate to "method" rather than "MyClass::method" or indeed "Full\NamespaceOf\MyClass::method". Some more details on what exactly it evaluates to for each type, and why, would be helpful. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
