On Sun, May 14, 2023 at 11:16 AM Rowan Tommins <rowan.coll...@gmail.com> wrote:
>
> On 13 May 2023 16:40:27 BST, Robert Landers <landers.rob...@gmail.com> wrote:
> > Most of the time, you want the unqualified name
> > ...
> >This is especially important when using traits and aliases:
>
> I don't think trait renaming is the same thing as aliasing a qualified name.
> In a sense, it's actually the opposite: with a trait, the compiler is
> inserting the code of the method under the new name, and the name from the
> trait can no longer be used to access it; for namespace imports, the compiler
> is substituting the fully-qualified name, and the *local alias* can no longer
> be used to access it.
As someone who has had limited interaction with the engine code itself
but has been using PHP, daily, for nearly 15 years, I'm not sure this
technical distinction makes sense in the context of programming in
PHP. When using traits, I don't think of it as 'inserting code', but
rather I think of it as 'using code' -- you do use `use TraitName`
after all and it is very similar to the top-level using statement.
> >In this case, if you want to use nameof(TEST) in an error message or
> >something else, it would be surprising to get \A\A instead of TEST.
>
> Would it? As I said before, my intuition was completely the opposite, that
> one of the advantages of writing nameof(TEST) rather than just 'TEST' is that
> it would resolve namespace imports the same way ::class does.
>
> Can you give an example of such an error message that would want to expose
> the local alias?
Which error message helps in resolving the error and would be written
by someone writing the code?
use function \Path\To\Function\Serializer\to_json as json_serializer;
// a bunch of code using json_serializer()
throw new Exception('json_serializer returned invalid json');
// or
throw new Exception('\Path\To\Function\Serializer\to_json returned
invalid json');
The former appears more natural and helps to trace the issue.
Otherwise, you end up in the file, trying to dig through usings to
figure out where usages of \Path\To\Function\Serializer\to_json are in
the file because, at first glance, it appears to not be there.
This would also be weird in the case of constants/functions in the
global space, because fully qualified names begin with a "\" which
feels unnatural when reading things meant for humans (such as error
messages).
> >So, for your example, we can instead call nameof(\Acme\bar(...))
> >instead of the aliased name when passing to another context:
> >
> >use function Acme\bar as foo;
> >...
> >#[SomeAttribute(callback: nameof(\Acme\bar(...))]
> >...
> >
> >I hope this helps!
>
>
> Not really, I'm afraid. If I have to write out the fully-qualified name, why
> would I bother with nameof() rather than just using a string?
If you write it in a string you really will, actually, have to write
out the fully qualified name because an IDE won't know you're
referencing a language construct and be able to autocomplete it for
you. If you rename the function or remove it, you won't be able to use
static analysis to locate these strings, you'll have to manually
search-and-replace the codebase, which opens up space for human error.
nameof() gives you a fighting chance of actually finding ALL the
usages in one go.
Personally, I've found that refactoring the names of things in PHP is
one of the most dangerous coding activities one can do in PHP. They
may be in a string, a database, on the wire via `serialize(),` or any
number of places. Making this a safer activity is one of my personal
goals.
> The more I read in this thread, the less I understand what the point of
> nameof() actually is, and how it would be used.
IMHO, this comment isn't constructive or helpful, how can I help you
understand? I'm more than happy to answer any and all questions, but
comments like this are pretty demoralizing when there are only a few
people discussing the feature in a community I'm relatively new to --
are my answers not clear enough, would a call help, or should I
reference other language's implementations and rationales? I don't
know the unwritten rules here, and being helpful and constructive can
move the conversation forward instead of reaching impasses.
Personally, I've been in war and dealt with far worse than this, but
someone who hasn't been through what I've been through may not be as
"thick-skinned" and just walk away. Just something to keep in mind for
future interactions.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
