Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42593
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 63.205.162.116 as permitted sender)
Message-ID: <496BCD33.4080703@zend.com>
Date: Mon, 12 Jan 2009 15:07:31 -0800
Organization: Zend Technologies
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Marcus Boerger <helly@php.net>
CC: internals@lists.php.net
References: <1016989528.20090112233204@marcus-boerger.de>
In-Reply-To: <1016989528.20090112233204@marcus-boerger.de>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] prototyping
From: stas@zend.com (Stanislav Malyshev)

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
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com