Hi!
1) a non static closure assigned to an instance changes the closures
this to be set to the actual object:
I'm not sure why would you expect this. If you have closure that has
some bound $var inside, and you use it in context which has another
$var, you don't expect that $var change to new scope's $var, do you?
I always thought of closures as taking their variables and context with
them, not changing them each time caller changes.
Also, this adds very new thing to PHP - objects that change while being
assigned. I am not sure it is a good thing.
4) Cloning an object assigns the properties correct. Right now we
increase the refcount only instead of cloning as that is the default
behavior of cloning. Since a normal variable splits on changes nothing
ever notices this. For oject types that do not support cloning this is
very different though. Now we cannot simply add cloning as then we'd
further change closure behavior. And this way we would not fix the this
pointer.
Besides the issue above with changing $this I'm not sure what would
proper clone do - i.e. by-val bound variables are by-val anyway, so it
shouldn't matter if they are cloned, and by-ref ones should be connected
anyway so again it doesn't matter. Am I missing something?
BTW, why would one clone closures anyway?
5) A closure assigned to a property can be called directly rather
than just by a temporary variable:
$obj->property = function() {}
$obj->property(); // valid call
This will get us into trouble IMHO, as it would not behave too well with
__get/__set and __call. I.e. if we have $foo->nosuchproperty() -
should we call __get or __call? So far variables implemented through
__get behave exactly like ones implemented through definition - but I
don't understand how to reconcile it with this.
I also don't like having special one-class check inside assignment
operators just for this narrow function - it doesn't look like good
generic code and I suspect for proper implementation may require
instanceof check on each assignment - which would be really bad.
2) The current behavior seems inconsistent as it matters where an
assignment of a closure to a proeprty is being performed. OR how a closure
is being created.
Of course it matters how (or, more precisely, where) the closure was
created - isn't it the whole point of closure?
3) If closures get callable by property directly then we end up in a
situation where we can have two methods with the same name. That means it
is discussable whether we want to allow assignment of a closure to a
member variable name that already exists as a private member function.
This is another thing - does it mean on each assignment we'd have to
check if member function with same name doesn't exist? That might break
some code in interesting ways too.
--
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
