Re: [RFC] Closure::call and Function Referencing as Closures

On 11 Aug 2014, at 12:08, Rowan Collins <rowan.collins@gmail.com> wrote: > I understand that &$foo->method won't work, but that's what I mean by > pre-supposing the proposed syntax. > > If you had a different syntax, such as £function (I know it's not a sensible choice, but > it's an example of something with no conflict), you *would* be able to implement > £$foo->method. It would "do the same thing calls do", which is call a non-static > method non-statically. > > So the question is, is it a) desirable and b) practical to come up with an implementation where > that is possible? Ah, I see what you’re saying. It’s certainly worth thinking about. & isn’t really the nicest of syntaxes. > Yep, that's my point - referencing a method without also referencing the class or object > it's bound to is not something that usually happens in PHP, so it feels odd to make it the > default behaviour here. > > Your proposal requires that to create a reference to a non-static method of the current object, > you would do something like this: > > $foo = &static::foo; > $foo->bindTo($this); > > We could imagine instead having a factory like Closure::wrap(callable $c), where the exact > equivalent would be: > > $foo = Closure::wrap([static::class, 'foo']); > $foo->bindTo($this); > > But you would never write it that way, because we have a way of specifying callables for > instance methods, so you'd just write this: > > $foo = Closure::wrap([$this, 'foo']); > > You might for some reason want to re-bind that to a different object (although I'm not > sure why, outside of things you'd expect to use Reflection for anyway), but the default would > be referencing its existing binding. I think Closure::bind(&FooBar::foo, ‘FooBar’); works well, but yes, I can see your point. > In which case what do you think of my second suggestion, of adding methods to allow people to > tell whether a closure is bound, bindable, etc? It makes it much easier to write defensive code if > you can predict errors rather than catching them. I’m totally in favour of that. One thing I’d like to see, if we introduce references for functions and classes and so on, is more reflection-like stuff. I think it’s a bit silly to have to instantiate reflection classes all the time. Given that closures are already objects, I see no reason why you should need to use ReflectionFunction on them. Rather, we should provide all this information on the object directly. -- Andrea Faulds http://ajf.me/