Hello,
I've opened the voting for the Closure from callable RFC -
https://wiki.php.net/rfc/closurefromcallable
Just to note, some people I've spoken to have expressed a desire to
have a more powerful syntax where 'bare' function names are used,
like:
callable(someFunctionName)
callable($this->method)
I fully agree with those people, however I can't see anyway to do that
before PHP 8. It would almost certainly need some clean up of the
allowed syntax to disambiguate what $this->method means for:
class Foo {
public $method;
public function method() { }
}
Leaving that top-level function name available for future versions,
where we might be able to support it properly, is one of the reasons
to use the more verbose function name.
cheers
Dan
Hello,
I've opened the voting for the Closure from callable RFC -
https://wiki.php.net/rfc/closurefromcallableJust to note, some people I've spoken to have expressed a desire to
have a more powerful syntax where 'bare' function names are used,
like:callable(someFunctionName)
callable($this->method)I fully agree with those people, however I can't see anyway to do that
before PHP 8. It would almost certainly need some clean up of the
allowed syntax to disambiguate what$this->methodmeans for:class Foo {
public $method;
public function method() { }
}Leaving that top-level function name available for future versions,
where we might be able to support it properly, is one of the reasons
to use the more verbose function name.
Hey Dan,
why would you need to support a $this->fieldName case though? If it's a field it probably already contains a closure (or, well, if you need to make a closure from arbitrary callable we could have a Closure::fromCallable named ctr). Instead of making a function 'callable()', we could make a language construct:
expr:
...
| T_CALLABLE '(' callable_expr ')'
callable_expr:
'$this->' function_name
| class_name '::' function_name
| function_name
This would have an advantage of being statically checked (hence easier refactoring in IDEs).
I see merging symbol tables as a pretty big of a deal for too much people, this thing alone could easily create another case of Python 3 syndrome.
why would you need to support a $this->fieldName case though?
Because to not support it would be to deliberately design in a new
flavor of inconsistency into the language. $obj->memb is a property
access in PHP. Making it suddenly mean "method" is a significant
change (and one which belongs in a major version if at all).
-Sara
On Sun, May 15, 2016 at 11:20 AM, Nikita Nefedov inefedor@gmail.com
wrote:why would you need to support a $this->fieldName case though?
Because to not support it would be to deliberately design in a new
flavor of inconsistency into the language. $obj->memb is a property
access in PHP. Making it suddenly mean "method" is a significant
change (and one which belongs in a major version if at all).-Sara
The whole idea is not in the syntax here, but in the notion
that this access can only be static (so there'd be no way to
do $cb = [$this, "methodName"]; callable($cb) - you'd have
to call Closure::fromCallable($cb) instead).
If you don't like the fact that $obj->methodName looks like
a field access then there are ways around this.
Because we still need a static way of exporting function
references (whether it'd be as a closure or array). Other
proposals were using $obj->method::FUNCTION syntax or something
similar for example...
Hello,
I've opened the voting for the Closure from callable RFC -
https://wiki.php.net/rfc/closurefromcallable
Voting was closed, the RFC has passed 40-0.
Thanks again to Bob, for helping with (aka doing most of) the code.
cheers
Dan
I'm sorry, I didn't follow the RFC discussion.
In general I like the idea, but why not to use Closure constructor?
$f = new Closure("some_func");
would look more readable than
$f = Closure::fromCallable("some_func");
Sorry, if this was already discussed before.
Thanks. Dmitry.
I'm sorry, I didn't follow the RFC discussion.
In general I like the idea, but why not to use Closure constructor?$f = new Closure("some_func");
would look more readable than
$f = Closure::fromCallable("some_func");
Sorry, if this was already discussed before.
Thanks. Dmitry.
Constructors can't be used as callbacks, so you wouldn't be able to map
this operation without yet another level of indirection.
A named constructor also leaves more space for later improvements, and is
quite a bit more expressive.
Marco Pivetta
I'm sorry, I didn't follow the RFC discussion.
In general I like the idea, but why not to use Closure constructor?
Hi Dmitry,
Several small to medium sized reasons that make me think it's the best way.
As Marco said, constructors cannot be passed as callbles, which for
whatever reason both myself and he seem to encounter as a problem more
than the average programmer. I had hoped to address this with this
RFC: https://wiki.php.net/rfc/callableconstructors - but the feedback
on that was massively negative so far.
Second, it's quite likely we're going to have other ways of creating
closures in the future. Having a default constructor that is 'special'
above the other named constructors is a source of API sadness for me.
would look more readable than
I actually seem to like named constructors more than default
constructors, and am totally used to reading them. That may be down to
my dislike of how constructors have special rules in being a little
bit static, and also being instance methods at the same time.
cheers
Dan