Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42610
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 72.14.220.157 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references:x-google-sender-auth;
        b=qjoflZ0q1iqjKDloIJC1Qzf0yje8ELBNg9ghs0zsCH6vDO7rraE/3acPVhpwrhhkEG
         t+0HgwizlImcIh+4SvtGQLt6XVDF/CAuWSTvKLPQbZ+7VheiTBE9wqlzc2QEF3vsMeDf
         wjKySihfsEty0w8/xexGrSpYyJxf+ubxYcKMQ=
Message-ID: <e666c3890901131144w44c3520fqe31e1a313d12a8e7@mail.gmail.com>
Date: Tue, 13 Jan 2009 20:44:57 +0100
Sender: ekneuss@gmail.com
To: "Stanislav Malyshev" <stas@zend.com>
Cc: "Marcus Boerger" <helly@php.net>, internals@lists.php.net
In-Reply-To: <496BCD33.4080703@zend.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <1016989528.20090112233204@marcus-boerger.de>
	 <496BCD33.4080703@zend.com>
Subject: Re: [PHP-DEV] [RFC] prototyping
From: webmaster@colder.ch ("Etienne Kneuss")

Hello,

On Tue, Jan 13, 2009 at 12:07 AM, Stanislav Malyshev <stas@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
> stas@zend.com   http://www.zend.com/
> (408)253-8829   MSN: stas@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