> Conversely, namespace imports are entirely local to the current file (or even
> a namespace{} block), and it's almost impossible for running code to see
> anything other than the expanded name.
>
> That doesn't mean that there aren't good reasons to have nameof() handle both
> things in the way proposed, I just think those reasons are probably different
> for the two cases.
That's a fair point. Maybe it is worth putting it up for a secondary
vote? I do have a strong preference, but I'd rather have full names
than no names, and doesn't change the RFC that much. If I'm
understanding correctly, it would only affect first-class callables
and constants.
> >> 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?
>
> To clear up any doubt, there was no sarcasm or aggression intended, I was
> genuinely requesting an example, which you have provided, so thank you.
FWIW, I didn't see it as a sarcastic question, but I'm a very
sarcastic person IRL... so maybe I did and I just ignored it. ¯\_
()_/¯ Either way, it was a good question.
> This seems to be a common sentiment indeed - people prefer long lists of "use
> function" to \ prefixes. It's not something I personally find unnatural, any
> more than "/images/logo.png" or "/etc/hosts", but I'm willing to concede I
> may be in a minority there.
I've seen hundreds of lines of nothing but `use`... it's terrifying
once you end up with a smattering of aliases thrown in, randomly, for
good measure. I don't think you're in the minority for people who've
been using PHP a long time -- or bitten by those files. As someone
who's had to wade through those codebases, aliases matter a lot and
I'd like to see them respected. I'm also realizing, as this discussion
goes on, that there is precedent for the expansion via ::class, so
maybe that is the right way to go after all? 🤔
> The biggest weakness of a generic "nameof" is that it still doesn't hint what
> kind of thing you want to mention.
The 'kind' of the thing doesn't really matter, we just want the name
of the thing. Basically, the string before `(...)`; the string after
`->`,`::`, `$`, or in the case of constants, the string itself.
> >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
>
> I'm genuinely sorry you felt this way, and it was absolutely not my intention
> to criticise you. If anything, it was meant to be an admission of my own
> failings, that I'd come into the discussion with the wrong preconceptions,
> because the use cases which immediately came into my head seemed to have
> contrasting requirements from the ones that you intended.
Thanks for explaining your intentions and no hard feelings from me. It
can feel like an 'island of one' putting an RFC forward for the first
time and a bit daunting when receiving negative feedback.
Maybe there should be a 'buddy system' for first-time submissions that
reach the discussion phase? A more experienced contributor could
volunteer to help guide the person through the process, answer weird
questions (like when is a secondary vote required or useful? I got
some feedback that it was a bad idea to include one, but why? I'm sure
there's some background there, but I'm in the dark with nobody to
reach out to and ask for history lessons), give informal feedback, and
someone to reach out to when you get stuck.
> To put things into a more productive context, then, I think a useful
> improvement to the RFC would be some examples of how you would use it with
> the different supported types, showing why the proposed semantics are useful
> for those scenarios.
I can do that for sure.
> On a different note, you've talked about how errors would be handled for
> nonexistent constructs, but given PHP's dynamic nature, there's also a
> question of *when* they would need to exist. For instance, assuming we go
> with Warnings, if I use nameof(Foo::bar), and class Foo is defined in a
> different file, there's a few things that could happen:
>
> - the resolution happens while compiling a single file, in which case it will
> always give a Warning, because any symbol outside the file is unknown
> - the resolution happens at runtime, and causes class Foo to be autoloaded
> - the resolution happens at runtime but doesn't trigger autoloading, so
> whether it gives a Warning or not depends on whether other code happens to
> have loaded the definition of Foo
> - probably other options that I haven't considered
>
> With the "no error handling" version, this becomes moot, because it's just a
> string manipulation exercise. That's how ::class currently works, apart from
> a few specific cases like static::class and $someInstance::class
I actually updated the RFC late last night with that information after
some feedback from Dan. ;)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
