Re: [PHP-DEV] Suggestion Method Constant

  100884
October 12, 2017 18:28 mathiasgrimm@gmail.com (Mathias Grimm)
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

On 12 October 2017 at 20:24, Michael Döhler <michaeldoehler@me.com> wrote:

> 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, >
  100886
October 12, 2017 18:33 michaeldoehler@me.com (=?utf-8?Q?Michael_D=C3=B6hler?=)
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 > >> On 12 October 2017 at 20:24, Michael Döhler <michaeldoehler@me.com> wrote: >> 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, >
  100887
October 12, 2017 21:32 pollita@php.net (Sara Golemon)
On Thu, Oct 12, 2017 at 2:33 PM, Michael Döhler <michaeldoehler@me.com> wrote:
> 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
October 13, 2017 06:41 mathiasgrimm@gmail.com (Mathias Grimm)
I also thought about the same for functions, just to be even more
consistent.
my_func::function

On 12 Oct 2017 23:32, "Sara Golemon" <pollita@php.net> wrote:

> On Thu, Oct 12, 2017 at 2:33 PM, Michael Döhler <michaeldoehler@me.com> > wrote: > > 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 >
  100890
October 13, 2017 08:00 me@kelunik.com (Niklas Keller)
> > 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
October 13, 2017 14:20 markyr@gmail.com (Mark Randall)
On 12/10/2017 22:32, Sara Golemon wrote:
 > 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
October 13, 2017 20:09 markyr@gmail.com (Mark Randall)
On 12/10/2017 22:32, Sara Golemon wrote:
> 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