Inconsistencies in callable, call_user_func and direct variable calls View as Markdown

There's then the question of what kind of object it would return - a
Closure? Some child or sibling of Closure? What methods could be usefully
provided?

Yes, it's a closure. I've actually fleshed this out quite a bit, and
there are a few important questions:

• With methods do you allow unbound closures? callable("Foo::method") ?
• How do you provide a context object? Two parameters? If so, what
  order? The object first makes more sense, but that means you have a
  string for your first parameter when there is only one, but an object
  if there are two. So you put the context second and it's kind of weird
  to do callable("method", $foo)

Also note that if we had a unified table for properties, methods and
constatns this is vastly simplified:

• $foo::method could provide an unbound, scoped closure
• $foo->method could provide a bound closure

Or you do alternative grammar rules inside of callable, such that
callable(foo::method) must would check for a method instead of a
constant.

All in all, I really wish we had unified properties, methods and
constants. It would also have the advantage that if you have a
property of an object that is a callable you could call it with normal
syntax $foo->property() instead of having to do things like $f = $foo->property; $f().

Callable might work, though.

Hi,

Am 19.03.2015 um 17:27 schrieb Sebastian B.-Hagensen:

Another way to unify array and string callback may be to use the
callable syntax and have it return a closure:
callable('strlen');
callable($object, $methodName);
callable('class', 'staticMethod')

but before that happens, we should make closures serializable.

What does closures being serializable have to do with this feature?

Hi Rowan,

On Fri, Mar 20, 2015 at 7:12 AM, Rowan Collins
<rowan.collins@gmail.com mailto:rowan.collins@gmail.com> wrote:

    Hi Sebastian,

    On Thu, Mar 19, 2015 at 9:48 PM, Sebastian B.-Hagensen
    <sbj.ml.read@gmail.com <mailto:sbj.ml.read@gmail.com>
    <mailto:sbj.ml.read@gmail.com <mailto:sbj.ml.read@gmail.com>>>
    wrote:

        2015-03-19 12:51 GMT+01:00 Yasuo Ohgaki
    <yohgaki@ohgaki.net <mailto:yohgaki@ohgaki.net>
        <mailto:yohgaki@ohgaki.net <mailto:yohgaki@ohgaki.net>>>:
        > Distinguishing array and callable is problematic.
        > Array callable is better to be deprecated in the long
    run. IMHO.

        Then how would you write an callback containing an already
        constructed object?
        $a = [$object, 'method'];

        The alternative is unnecessarily cumbersome:
        $a = function($methodArg1, $methodArg2) use($object) { return
        $object->method($methodArg1, $methodArg2); };


    I'm not proposing deprecate it soon, but in the long run.
    It will need a decade to deprecate it.


It is not time that is needed, but an alternative way of
expressing "use this instance method as a callback", such as those
discussed elsewhere in the thread.

I replied how it could be deprecated.
I'm not commenting for it, but the deprecation discussion.
You cannot restrict discussion to what you would want, can it?

I had no intention of restricting the discussion in any way, apologies
if it came across that way.

Perhaps what I should have said is it is not only time that is needed

• we need to design the replacement before it's worth even thinking
  about deprecating something.

Regards,

--
Rowan Collins
[IMSoP]