Everything

php

[RFC][VOTE] Closure from callable

php.internals

Dan Ackroyd

10 years ago

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

Nikita

10 years ago

> On 15 May 2016, at 20:29, Dan Ackroyd <danack@basereality.com> wrote:
>
> 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.

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.

Sara Golemon

10 years ago

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

Nikita

10 years ago

On Mon, 16 May 2016 03:56:38 +0300, Sara Golemon <pollita@php.net> wrote:

> 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...

Dan Ackroyd

10 years ago

> On 15 May 2016, at 20:29, Dan Ackroyd <danack@basereality.com> wrote:
> 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

Dmitry Stogov

10 years ago

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.

________________________________________
From: Dan Ackroyd <danack@basereality.com>
Sent: Sunday, May 15, 2016 8:29:22 PM
To: internals@lists.php.net
Subject: [PHP-DEV] [RFC][VOTE] Closure from callable

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Marco Pivetta

10 years ago

On 16 May 2016 at 10:31, Dmitry Stogov <dmitry@zend.com> wrote:

> 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

http://twitter.com/Ocramius

http://ocramius.github.com/

Dan Ackroyd

10 years ago

On 16 May 2016 at 09:31, Dmitry Stogov <dmitry@zend.com> wrote:

> 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