Re: [RFC] prototyping

On 1/14/2009 01:15, Stanislav Malyshev wrote:

Hi!

Also, this adds very new thing to PHP - objects that change while being assigned. I am not sure it is a good thing.

Well Closures are a brand new thing in PHP. So far we had nothing even remotely close to the closures we have right now.

There are a lot of different features in PHP, that's not the reason to turn the engine into a salad of special cases and exceptions. That's why making Closure an object and having __invoke was a good idea - because it fits what the engine already does very well. Having special case just for one class doesn't fit it so well.

you wrote. And in my opinion it also makes the most sense. A closure keeps its state.

I consider $this be a part of this state. Maybe if you really need it it'd be fine to do something like $closure->setThis($object)...

Why would you call __get() here? Becasue I did that by mistake in my very

Imagine such code: class Contains { private $_store; function __set($n, $v) { $this->_store[$n] = $v; } function __get($n) { return $this->_store[$n]; } } Pretty standard class. Now imagine you do this: $c = new Contains(); $c->foo = "bar"; echo $c->foo; works well and basically you see Contains as regular object and couldn't care less it has handlers and not properties. Now this: $c->bar = function() { } $c->bar(); what happens here? You can't get the value of "bar" without calling __get and if you call __call instead that means you either lost $c->bar or you have two kinds of properties now - ones that call __get and ones that don't. I don't see how it is good.

That is one example of convoluted code that is already possible. If a developer creates such a mess is his fault. As Marcus said, it is already possible to call properties. All we have to do is implement __call(). Not being forced to implement __call in cases where we want object augmentation with lambdas is just syntactic sugar. I agree though that a rebind()/setThis() method on the Closure object is needed, but $this should be rebound by default. Auto-magically binding $this to the current object, whatever that may be, is a missing feature that requires a developer to pass the instance as an argument to that lambda. class A {

    protected $_lambdas = array();

    public function __set($name, $lambda)
    {
        $this->_lambdas[$name] = $lambda;
    }

    public function __call($lambda, $args)
    {
        $args = array_merge($this, $args);
        return call_user_func_array($this->_lambdas[$lambda], $args);
    }

} $a = new A; $a->foo = function($this) {

    var_dump($this);

}; $a->foo(); Now, the above code is already possible, but... by implementing callable properties a developer is spared the effort of implementing a __call() method. The only problem now is that by deciding to not implement __call() he loses a nice opportunity of passing the instance object and he's left with some ugly alternatives: class B {} $b = new B; $b->foo = function($this) {

    var_dump($this);

}; $b->foo($b); // how would be the above call different than? $foo = function($object) {

    var_dump($object);

} $foo($b); // Or would you believe this is just fine? $b->foo = function() use ($b) {

    var_dump($b);

}; $b->foo(); Sooner or later, people would want that use statement to be dismissed for an auto-magically bound $this. It's also the problem of accessing protected and private members. JavaScript does automatic binding of the "this" instance which is actually a key point in prototyping. Well, strictly speaking this is not prototyping, is augmentation. Adding members to the JS prototype object means that *any* existing and further instances will share those members. Augmentation is just about adding members to an existing instance. Real prototyping is though possible in PHP 5.3: class A {

    /**
     * Lambdas available to all instances
     */
    public static $lambda;

    public function __call($method, $args)
    {
        $method = self::$lambda;
        return call_user_func_array($method, $args);
    }

} A::$lambda = function() {

    return 'foo';

}; $a1 = new A; $a2 = new A; echo $a1->lambda(); echo $a2->lambda(); The problem of binding $this appears again, but I believe this use case is much harder to solve because there's no $this in the moment we add lambdas to the class. Anyway, it's a point to consider.

No, becasue Closure cannot be derived as it is a final class. If we change

Why it's a final class? Any special reason for that?

It matters how you bind static variables to it as they are taken from the context. And by the binding you keep the context. Sure all right. But we bind this in a completely different way.

I see no reason to have two contexts in closure - one bound one way and another bound another way. I think context is a context - it's where the closure was created.

different from an assignment outside the class? And it gets even better, if you assign that closure to another object it gets private access to the other classes members; plus you can bind it to the new classes private

That's the whole point of the closure - if you make object-bound closure you can pass accessors to private variables to external classes. If you don't want it - either don't access privates in your closure or make the closure static. The whole point of the closure is that you can keep the context with the closure and thus give other scope regulated access to your scope.

In this particular case I think having callable properties has less to do with closures (I mean capturing context, not lambdas) and more to do with extending functionality of existing classes and objects without a need for creating additional classes. It's also about overriding existent behavior. In JavaScript, if you don't have a String.trim() function you add it to the prototype. From that moment on, all your strings have a trim() method: String.prototype.trim = function() {}; Of course, this is nice for primitive types that have some form of syntactic sugar representation, quotes in case of strings. So now I'm able to do: var trimmed = " has spaces ".trim(); This is of course not the case with PHP, but as I said, this feature has less to do with closures.

I don't see a reason for this. But people might differ. And at the end of the day the problems arising from this are the least evil.

The least between what and what? I don't see any problem or "evil" with what we have now except for missing exotic feature of rebinding closures - which would be a huge WTF for me if all closures worked this way (I definitely expect closure to keep its context and not switch it each time I pass it around), but if there was a special way to make it work this way (as setThis mentioned above or any other way) and it would not conflict with other features and not require dirty hacks on the engine I wouldn't mind.