Hello,
On Tue, Jan 13, 2009 at 12:07 AM, Stanislav Malyshev <s...@zend.com> wrote:
> 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.
It will not be able to respect the inheritance rules as well (at least
how it is implemented currently) :
class A {
public function plop(){}
}
class B extends A {}
$b = new B; $b->plop = function(){};
$b->plop(); //will still call A::plop().
And if by any chance there is a way to make that work, it will still
cause trouble with internal classes that checks for inherited methods
at instantiation only.
Looks like it would either introduce a lot of inconsistencies, or a
lot of edge cases to fix by adding exceptions in the code.
Regards,
> --
> 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
>
>
>
>
--
Etienne Kneuss
http://www.colder.ch
Men never do evil so completely and cheerfully as
when they do it from a religious conviction.
-- Pascal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
