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

On 4 Aug 2014, at 13:27, Marco Pivetta <ocramius@gmail.com> wrote: > The fact that I'm arguing about is "yet another method to maintain" for an API > that can simply live in userland (and is easier to maintain/upgrade/etc)... > Unless there's a huge overhead, I don't see a problem with creating new closures: I > do a lot of performance-sensitive stuff with Closure::bind() and I > don't see how this API could help me. Well, perhaps this API is not aimed at you specifically. The broader question is why *shouldn’t* we allow binding $this at runtime like we do for any other parameter? Creating a closure only to immediately throw it away is a waste of code and time. Since we can permit this, it is useful, and it doesn’t cause any problems, I don’t see why we shouldn't. If it’s really such a maintainability problem (I wouldn’t say so, the function’s quite simple), then you can get me to maintain it. After all, I wrote it. > Why do you actually need parameter information here? > Starting from PHP 5.6, dynamic parameters can be passed on via variadics anyway. By-ref and > by-val is also no big deal as well. > > This kind of call can be recognized by static analyzers, and can be refactored by IDEs. It still has the problem of not allowing re-scoping or arbitrary $this binding. Your solution works only for global functions. It also removes the benefit of knowing at the point of reference whether the function actually exists. > FooBar::methodName::function vs FooBar::function - clear and simple IMO. It might be clear and simple, but I don’t think it’s realistic. I’m not sure if it’s even possible in the parser, as you’d be fetching a class then suddenly backtracking and deciding you actually want to do something else entirely. Of course, with Nikita’s AST, this probably is possible. > How about if I have a class with a constant named function? > > Not allowed by the language Good point. > How do you propose to implement this pseudo-class system where functions act like classes in > only one case, when fetching this fake class constant? > > I'm not: ::function is not a constant, it would be > recognized by the parser directly. Right, but at least under the current parser, you couldn’t do that, to the best of my knowledge. I think using ::function over-complicates things. That said, it is another option, just not one we could implement immediately or that I personally am particularly fond of. -- Andrea Faulds http://ajf.me/