FAQ
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

Search Discussions

  • Nikita Nefedov at May 15, 2016 at 6:20 pm

    On 15 May 2016, at 20:29, Dan Ackroyd 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 at May 16, 2016 at 12:56 am

    On Sun, May 15, 2016 at 11:20 AM, Nikita Nefedov 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 Nefedov at May 16, 2016 at 8:40 am

    On Mon, 16 May 2016 03:56:38 +0300, Sara Golemon wrote:
    On Sun, May 15, 2016 at 11:20 AM, Nikita Nefedov 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...
  • Dmitry Stogov at May 16, 2016 at 8:31 am
    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 at May 16, 2016 at 8:35 am

    On 16 May 2016 at 10:31, Dmitry Stogov 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 at May 16, 2016 at 8:12 pm

    On 16 May 2016 at 09:31, Dmitry Stogov 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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedMay 15, '16 at 5:29p
activeMay 16, '16 at 8:12p
posts7
users5
websitephp.net

People

Translate

site design / logo © 2018 Grokbase