Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120399
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-441-ga3ab13cd6d-fm-20230517.001-ga3ab13cd
Mime-Version: 1.0
Message-ID: <e082a75d-b085-48ae-a35e-22e092174647@app.fastmail.com>
In-Reply-To: 
 <CAPzBOBM+LA-BjmQjaxFnQ121U6eR9UXjKob3AAuPjT0uzhYGOg@mail.gmail.com>
References: 
 <CAPzBOBPQzV=EfYgWL50-mEkjjDOua1brbLyNJ3T89Og+HuUkfA@mail.gmail.com>
 <5e35344e-e885-4b65-8f86-2cb43330af46@app.fastmail.com>
 <CAPzBOBM+LA-BjmQjaxFnQ121U6eR9UXjKob3AAuPjT0uzhYGOg@mail.gmail.com>
Date: Thu, 25 May 2023 17:29:14 +0000
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] [Discussion] nameof
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, May 25, 2023, at 3:21 PM, Robert Landers wrote:
> On Tue, May 16, 2023 at 11:56=E2=80=AFPM Larry Garfield <larry@garfiel=
dtech.com> wrote:
>>
>> On Sat, May 13, 2023, at 7:27 AM, Robert Landers wrote:
>> > Hello Internals,
>> >
>> > It is with much trepidation and excitement that I'd like to announce
>> > the `nameof` RFC (https://wiki.php.net/rfc/nameof). It has changed
>> > quite a bit in the last couple of days, so if you haven't seen the
>> > latest draft, please check it out.
>> >
>> > Essentially, it allows using `nameof()` anywhere a string can be us=
ed,
>> > even in static contexts. From a developer's perspective, it is a
>> > string and from the engine's perspective, it is also mostly a string
>> > (depending on how deep we want to go on error checking -- see the
>> > RFC).
>> >
>> > If anything is unclear or if I missed something, please let me know.
>> >
>> > Robert Landers
>> > Software Engineer
>> > Utrecht NL
>>
>> Some concrete use cases that I know I run into, and would thus be wha=
t I'd hope an RFC like this would resolve:
>>
>> Router::addRoute('\my\space\my_action_function`);
>>
>> Right now that has to be a string with a full namespace.  You cannot =
use a FCC here, because you want to use this data to compile the router =
somehow.  So in this case we want the full namespace.  (Ignore function =
autoloading for now.)
>>
>> Router::addRoute(MyClass::actionMethod);
>>
>> Various frameworks have different custom syntaxes for this case.  It'=
s also not clear if this refers to a static method, or a "instantiate th=
is out of the container first and then call this method" approach.  In t=
hese cases, we would want the full class name, and the method name on it=
s own, as separate strings.
>>
>> In my FP library, I have code like this:
>>
>> function prop(string $prop): \Closure
>> {
>>     return static fn (object $o): mixed =3D> $o->$prop;
>> }
>>
>> function method(string $method, ...$args): \Closure
>> {
>>     return static fn (object $o): mixed =3D> $o->$method(...$args);
>> }
>>
>> Which you can then use in a pipe, like so:
>>
>> pipe($someObject, method('foo'), prop('bar'));
>>
>> Or, more realistically, you'd use method() and prop() in a map or fil=
ter call within the pipe.
>>
>> In this case, you want just the method/property name on its own, with=
out a namespace, because it will be used in the context of an object to =
be named later.
>>
>> How would nameof() handle each of these cases?
>>
>> --Larry Garfield
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: https://www.php.net/unsub.php
>>
>
> Hey Larry,
>
> I did not ignore you. I somehow missed your question while researching
> something after reading the first half of your email last week -- I,
> apparently, never made it to the second half until today. I'll get to
> that in a sec.

Not to worry.

>> pipe($someObject, method('foo'), prop('bar'));
>>
>> Or, more realistically, you'd use method() and prop() in a map or fil=
ter call within the pipe.
>>
>> In this case, you want just the method/property name on its own, with=
out a namespace, because it will be used in the context of an object to =
be named later.
>
> So, for example, you could replace your pipe with:
>
> pipe($someObject, method(nameof($someObject->foo(...))),
> prop(nameof($someObject->bar)))
>
> It looks a bit wordy, but PHP differentiates between properties and
> methods by using a parenthesis/bracket (hence if you want to call a
> property that is actually a closure, you have to write ($this->prop)()
> otherwise it will look for a method called prop and fail to find it).
>
> At runtime, you would receive a warning on this line if $someObject is
> missing a method called foo or a property called bar (if the
> error-detecting version is chosen). This would result likely result in
> an actual error in your method() and prop() functions. However, it
> should make debugging from logs a bit easier since you'll (hopefully)
> notice the warning.

I figured it would be something like that.  I don't know how it would be=
 done better, but it also makes the code notably more verbose, and clums=
y with the extra ()s.  So, I'm not sure if it's a net-win or not.

> Now, why I didn't answer you and only made it half way through your em=
ail...
>
> Much of the earlier discussion was about functions/consts being
> fully-qualified names. I was mostly against it, because I was offering
> 'both' qualified and unqualified. However, your initial examples
> really hit home for me and I did a bit of spelunking in various
> popular PHP codebases for class::name (since that is really the only
> similar thing) and for stringified names of things. I'm now convinced
> that FQL's should be returned for functions, and constants (but not
> methods and properties).

Mission accomplished, then. :-)  And yes, I agree with that conclusion.

> Thus, your example:
>
> Router::addRoute('\my\space\my_action_function`);
> Router::addRoute(MyClass::actionMethod);
>
> could be rewritten as
>
> use function \my\space\my_action_function;
> Router::addRoute(nameof(my_action_function));
> Router::addRoute(nameof(MyClass::actionMethod(...)));
>
> I'll have to think about how to word this in RFC, but I'll do so as
> soon as I figure it out.

>> use function \my\space\my_action_function;
>> Router::addRoute(nameof(my_action_function));
>> Router::addRoute(MyClass::name . '::' . nameof(MyClass::actionMethod(=
...))); // or something since the class name is not returned with nameof=
().

The function one seems reasonable.  The method version, though, looks su=
per ugly and hard to implement.  I'd be much more likely to just split i=
t into two arguments and leave the second as a string, TBH. =20

Using a :: pseudo-constant suffix rather than a ()-based construct would=
 help with the syntax clumsiness in both cases, but wouldn't entirely el=
iminate it.  I don't have a really great answer here, unfortunately.  I =
think I'd marginally prefer a ::name suffix at this point just for synta=
ctic convenience, but I'm still undecided if the overall tradeoff is wor=
th it.  (For ::name, probably, as that would be a much lighter syntax im=
pact for those unusual cases that it's needed.)

--Larry Garfield