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.
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.
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.
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
