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,
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 oneI 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,
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
MichaelAm 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 oneI 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,
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
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
MichaelAm 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 oneI 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 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
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: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
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
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:
- 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.
- 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();
- 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
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:
- 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.
- 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();
- 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
Hi Mathias,
Mathias Grimm wrote:
I would like to suggest a method constant that could be used the same way
we use the ::class oneI 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/
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 would like to suggest a method constant that could be used the same way
we use the ::class oneI 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 ofstrlen()
.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/
Hi Mathias,
Mathias Grimm wrote:
I would like to suggest a method constant that could be used the same way
we use the ::class oneI 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. sostrlen
would resolve
to a closure ofstrlen()
.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
Hi Niklas,
Niklas Keller wrote:
Hi Mathias,
Mathias Grimm wrote:
I would like to suggest a method constant that could be used the same way
we use the ::class oneI 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. sostrlen
would resolve
to a closure ofstrlen()
.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.
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/