# Suggestion Method Constant

- Thread: https://externals.io/message/100883
- Original archive: https://news-web.php.net/php.internals/100883
- Started by Mathias Grimm on 2017-10-12T17:43:57+00:00
- Messages: 13
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #100883 — Mathias Grimm — 2017-10-12T17:43:57+00:00

URL: https://externals.io/message/100883#100883

I would like to suggest a method constant that could be used the same way
we use the ::class one

I don't have a strong personal preference but it could be something like:

MyController::myActionMethod::method, no sure about the internals but it
would be consistent with the one for the class.

Cheers,

---

## #100885 — michaeldoehler@me.com — 2017-10-12T18:24:14+00:00

URL: https://externals.io/message/100883#100885 · In reply to: #100883

Hi,

Same i have in mind, for example: MyClass@myMethod

To make also some method call routing easier, e.g. in userland routers.

Transform the current approach:

$app->get("/foo", [MyClass::class, "myMethod"]);

To:

$app->get("/foo", MyClass@myMethod);

This will ease a lot, e.g. for refactoring, IDE usage and completes the code as configuration approach for PHP.

Thanks
Michael

> Am 12.10.2017 um 19:43 schrieb Mathias Grimm <mathiasgrimm@gmail.com>:
> 
> I would like to suggest a method constant that could be used the same way
> we use the ::class one
> 
> I don't have a strong personal preference but it could be something like:
> 
> MyController::myActionMethod::method, no sure about the internals but it
> would be consistent with the one for the class.
> 
> Cheers,

---

## #100884 — Mathias Grimm — 2017-10-12T18:28:03+00:00

URL: https://externals.io/message/100883#100884 · In reply to: #100885

The only problem with the @ symbol is the lack of consistency with the
other constants class constants are also MyClass::MY_CONST, or
MyClass::class, so I think it makes sense to also be
MyClass::myMethod::method



> Hi,
>
> Same i have in mind, for example: MyClass@myMethod
>
> To make also some method call routing easier, e.g. in userland routers.
>
> Transform the current approach:
>
> $app->get("/foo", [MyClass::class, "myMethod"]);
>
> To:
>
> $app->get("/foo", MyClass@myMethod);
>
> This will ease a lot, e.g. for refactoring, IDE usage and completes the
> code as configuration approach for PHP.
>
> Thanks
> Michael
>
> > […]

---

## #100886 — michaeldoehler@me.com — 2017-10-12T18:33:20+00:00

URL: https://externals.io/message/100883#100886 · In reply to: #100884

Hi,

I am open for any approach, but maybe we have to differentiate between class constants and method references? 

Michael 

> Am 12.10.2017 um 20:28 schrieb Mathias Grimm <mathiasgrimm@gmail.com>:
> 
> The only problem with the @ symbol is the lack of consistency with the other constants class constants are also MyClass::MY_CONST, or MyClass::class, so I think it makes sense to also be MyClass::myMethod::method
> 
> > […]

---

## #100887 — Sara Golemon — 2017-10-12T21:32:29+00:00

URL: https://externals.io/message/100883#100887 · In reply to: #100886

> I am open for any approach, but maybe we have to differentiate between class constants and method references?
>
Given the discussion we had around the namespace separator (and why we
DIDN'T go with ::), there may be similar issues here.  Maybe not,
given the final component is specifically T_METHOD, but it should be
prototyped to be sure.

As to what such a reference would evaluate to:   Foo::bar::method -> [
Foo::class, 'bar' ] as Michael Döhler suggests seems the obvious
answer, but (Foo::class.'::bar') may be what some would expect.
Ideally we'd have first-class references to functions.

-Sara

---

## #100888 — Mathias Grimm — 2017-10-13T06:41:59+00:00

URL: https://externals.io/message/100883#100888 · In reply to: #100887

I also thought about the same for functions, just to be even more
consistent.
my_func::function



> On Thu, Oct 12, 2017 at 2:33 PM, Michael Döhler <michaeldoehler@me.com>
> wrote:
> > […]
> class constants and method references?
> > […]
> Given the discussion we had around the namespace separator (and why we
> DIDN'T go with ::), there may be similar issues here.  Maybe not,
> given the final component is specifically T_METHOD, but it should be
> prototyped to be sure.
>
> As to what such a reference would evaluate to:   Foo::bar::method -> [
> Foo::class, 'bar' ] as Michael Döhler suggests seems the obvious
> answer, but (Foo::class.'::bar') may be what some would expect.
> Ideally we'd have first-class references to functions.
>
> -Sara

---

## #100890 — Niklas Keller — 2017-10-13T08:00:21+00:00

URL: https://externals.io/message/100883#100890 · In reply to: #100888

>
> I also thought about the same for functions, just to be even more
> consistent.
> my_func::function


I already had the exact same ideas, but didn't propose them yet.

$obj::foo::method could be used for instance methods, while
Obj::foo::method could be for static methods.

Regards, Niklas

---

## #100895 — Mark Randall — 2017-10-13T14:20:03+00:00

URL: https://externals.io/message/100883#100895 · In reply to: #100887

> Ideally we'd have first-class references to functions.
 > -Sara

To chime in..

To my mind, references to functions is the holy grail so far as 
beginning to clean up the entire ecosystem around function calls.

IMHO directly referencing MyClass::StaticFunction eventually needs to 
return a "Function" class that is directly invokable.

I see 3 contexts that the parser would need to handle:



1. Standard Calling

MyClass::StaticFunction(1, 2, 3);
my_function(1, 2, 3)
$inst->my_function(1234);

Obviously returning a full function object to useland for every call 
would be considered wasteful, so the parser would need to call these as 
before.



2. Returning a native "Function" class, an __invokeable hybrid of 
Callable and Reflection;

$method = MyClass::StaticFunction;
$method(1, 2, 3);

$method = $inst->my_function; /* bind to $inst */
$method(1, 2, 3);

$method->getName();
$method->getArgumentCount();
$method->getBinding();




3. Returning closures when the argument list includes one or more 
late-bound values, so we can finally put the pipe operator to bed at the 
same time as getting a bunch of other power from it.

$method = MyClass::StaticFunction($1, 'Arg 1', 'Arg 3);
$method('Arg 1');

$method = $inst->my_function('Arg 1', 'Arg 2', $1);
$method('Arg 3');

chain(
   'Random String',
   func_1($1, 'Hello', 'World'),
   func_2($1, 'Peace', 'Out'),
   func_3('ThisOneNeeds', 'Arg3ReplacingInstead', $1),
   func_3($1, $1, 'HowAboutOneWhichUsesTheSameArgumentTwice')
);

function chain($start, ... $fns) {
    foreach ($fns as $fncall) {
      $start = $fncall($start);
    }

    return $start;
}


--
Mark Randall

---

## #100896 — Mark Randall — 2017-10-13T20:09:05+00:00

URL: https://externals.io/message/100883#100896 · In reply to: #100887

> answer, but (Foo::class.'::bar') may be what some would expect.
> Ideally we'd have first-class references to functions.
> 
> -Sara
> 

To chime in..

To my mind, references to functions is the holy grail so far as 
beginning to clean up the entire ecosystem around function calls.

IMHO directly referencing MyClass::StaticFunction eventually needs to 
return a "Function" class that is directly invokable.

I see 3 contexts that the parser would need to handle:


1. Standard Calling

MyClass::StaticFunction(1, 2, 3);
my_function(1, 2, 3)
$inst->my_function(1234);

Obviously returning a full function object to useland for every call 
would be considered wasteful, so the parser would need to call these as 
before.



2. Returning a native "Function" class, an __invokeable hybrid of 
Callable and Reflection;

$method = MyClass::StaticFunction;
$method(1, 2, 3);

$method = $inst->my_function; /* bind to $inst */
$method(1, 2, 3);

$method->getName();
$method->getArgumentCount();
$method->getBinding();




3. Returning closures when the argument list includes one or more 
late-bound values, so we can finally put the pipe operator to bed at the 
same time as getting a bunch of other power from it.

$method = MyClass::StaticFunction($1, 'Arg 1', 'Arg 3);
$method('Arg 1');

$method = $inst->my_function('Arg 1', 'Arg 2', $1);
$method('Arg 3');

chain(
   'Random String',
   func_1($1, 'Hello', 'World'),
   func_2($1, 'Peace', 'Out'),
   func_3('ThisOneNeeds', 'Arg3ReplacingInstead', $1),
   func_3($1, $1, 'HowAboutOneWhichUsesTheSameArgumentTwice')
);

function chain($start, ... $fns) {
    foreach ($fns as $fncall) {
      $start = $fncall($start);
    }

    return $start;
}


--
Mark Randall

---

## #100897 — Andrea Faulds — 2017-10-14T01:02:02+00:00

URL: https://externals.io/message/100883#100897 · In reply to: #100883

Hi Mathias,

Mathias Grimm wrote:
> I would like to suggest a method constant that could be used the same way
> we use the ::class one
>
> I don't have a strong personal preference but it could be something like:
>
> MyController::myActionMethod::method, no sure about the internals but it
> would be consistent with the one for the class.
>
> Cheers,
>

I've long wanted to make constant lookups fall back to a closure of the 
correspondingly-named function, where one exists. so `strlen` would 
resolve to a closure of `strlen()`.

Thing is that classes are weird. We sort of have three different things 
with sometimes-similar syntax: constants, methods and properties. 
foo::bar is a constant, foo::bar() is a function, $foo->bar() is a 
function, but $foo->bar is not a constant. So, if I want $foo->bar to 
resolve to a method, then $foo::$bar should too, even though that makes 
no sense. The PHP static property syntax is the bane of my existence.

-- 
Andrea Faulds
https://ajf.me/

---

## #100898 — michaeldoehler@me.com — 2017-10-14T10:41:35+00:00

URL: https://externals.io/message/100883#100898 · In reply to: #100897

Hi,

maybe the introduce of a complete new syntax for method references would solve the issues? Maybe coming back to e.g. "#" ("@" is still used for supressing errors,...)?

As mentions before all kinds can be simplified or? See:

MyClass#myMethod

#function

This should resolve in an object as mentioned before, in this object you have further informations, e.g.

$ref = MyClass#myMethod;
$ref->isStatic();
...

I think an seperate solution for method/Funktion references is more realistic than changing core things...

Greetings
Michael 

> Am 14.10.2017 um 03:02 schrieb Andrea Faulds <ajf@ajf.me>:
> 
> Hi Mathias,
> 
> Mathias Grimm wrote:
> > […]
> 
> I've long wanted to make constant lookups fall back to a closure of the correspondingly-named function, where one exists. so `strlen` would resolve to a closure of `strlen()`.
> 
> Thing is that classes are weird. We sort of have three different things with sometimes-similar syntax: constants, methods and properties. foo::bar is a constant, foo::bar() is a function, $foo->bar() is a function, but $foo->bar is not a constant. So, if I want $foo->bar to resolve to a method, then $foo::$bar should too, even though that makes no sense. The PHP static property syntax is the bane of my existence.
> 
> -- 
> Andrea Faulds
> https://ajf.me/

---

## #100899 — Niklas Keller — 2017-10-14T11:00:01+00:00

URL: https://externals.io/message/100883#100899 · In reply to: #100897

>
> Hi Mathias,
>
>
> Mathias Grimm wrote:
>
> > […]
> I've long wanted to make constant lookups fall back to a closure of the
> correspondingly-named function, where one exists. so `strlen` would resolve
> to a closure of `strlen()`.
>
> Thing is that classes are weird. We sort of have three different things
> with sometimes-similar syntax: constants, methods and properties. foo::bar
> is a constant, foo::bar() is a function, $foo->bar() is a function, but
> $foo->bar is not a constant. So, if I want $foo->bar to resolve to a
> method, then $foo::$bar should too, even though that makes no sense. The
> PHP static property syntax is the bane of my existence.


Please no fallbacks, thanks. It was already a mistake for namespaced
functions.

Regards, Niklas

---

## #100901 — Andrea Faulds — 2017-10-15T19:10:42+00:00

URL: https://externals.io/message/100883#100901 · In reply to: #100899

Hi Niklas,

Niklas Keller wrote:
> > […]
>
>
> Please no fallbacks, thanks. It was already a mistake for namespaced
> functions.


I'm not exactly a huge fan of fallbacks myself. If we were to have such 
a fallback, I'd like to deprecate overlapping method/property/constant 
names and throw warnings to that effect, with an obvious goal of 
eventually merging those namespaces.

…hey, if we merged properties and constants together, you could do 
Foo::bar = $baz; instead of having to use the annoyingly inconsistent 
Foo::$bar syntax. I'd love that.

-- 
Andrea Faulds
https://ajf.me/