Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42443
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender)
Date: Fri, 2 Jan 2009 13:05:46 +0100
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <444946936.20090102130546@marcus-boerger.de>
To: =?iso-8859-15?Q?David_Z=FClke?= <david.zuelke@bitextender.com>
CC: Marcus Boerger <helly@php.net>, 
	"Hannes Magnusson" <hannes.magnusson@gmail.com>, 
	"Lars Strojny" <lstrojny@php.net>, 
	"PHP Internals" <internals@lists.php.net>
In-Reply-To: <A2475678-E055-4C0E-BBAA-B6A59C45E36F@bitextender.com>
References: <08AA10DA-2704-415C-8A8C-893C89990DC1@bitextender.com> <868073456.20081231173818@marcus-boerger.de> <1230746348.25966.3.camel@localhost> <8710064882.20081231201259@marcus-boerger.de> <7f3ed2c30812311133m708bcab1s746f9ca7c3129542@mail.gmail.com> <18322421.20090101160939@marcus-boerger.de> <533383914.20090101170623@marcus-boerger.de> <150CBF28-ADB6-4ED3-9201-4483518D6129@bitextender.com> <886533446.20090101175039@marcus-boerger.de> <A2475678-E055-4C0E-BBAA-B6A59C45E36F@bitextender.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Re: [PHP-DEV] __invoke() weirdness
From: helly@php.net (Marcus Boerger)

Hello David,

Friday, January 2, 2009, 8:03:22 AM, you wrote:

> Marcus,

> thanks!

> Why is it
> Test::{closure}()
> {closure}()

> and not
> Test::{closure}()
> Test::{closure}()

> in that test, though? Is it because func1() "was there" from the  
> Engine's POV after the ctor was called? AFAICT, that's the only  
> difference between the two.

No, one is created inside the object instance and one is created outside.
So one has a bound $this pointer while the other has not. And the class
comes from the bound $this. So if there is no bound $this there is no class
and thus the closure becomes a function rather than a method.

marcus

> Cheers,

> - David



> On 01.01.2009, at 17:50, Marcus Boerger wrote:

>> Hello David,
>>
>>  I added test closure_037.phpt to demonstrate this.
>>
>> marcus
>>
>> Thursday, January 1, 2009, 5:23:08 PM, you wrote:
>>
>>> Hi folks,
>>
>>> first of all, thank you Marcus for implementing this. Very cool.
>>
>>> As for the __get()/__getClosure() stuff, I don't think it's necessary
>>> or even an issue. One can never simply do $this-
>>>> getOverloadPropertyWithInvoke() anyway, because if the prop is not
>>> there, a fatal error would be the result. An __isset() call has to be
>>> made first along with an (instanceof Closure ||
>>> method_exists('__invoke')) check in userspace code.
>>
>>> Which brings me to the next question - will
>>> $method = 'something';
>>> $bar->$method();
>>> work? Not sure if it's necessary; just curious for the most part.
>>
>>> - David
>>
>>
>>> On 01.01.2009, at 17:06, Marcus Boerger wrote:
>>
>>>> Hello Hannes,
>>>>
>>>> as discussed online. At the moment we should not have any __get()
>>>> calls during method resolution. The newly updated patch does that
>>>> now. And I think we are now safe to submit.
>>>>
>>>> In the future we could think of adding __getClosure() which would be
>>>> called to resolve a dynamic closure. But for the moment we do not  
>>>> need
>>>> it badly and the patch with the increased consistency is good  
>>>> enough.
>>>>
>>>> marcus
>>>>
>>>> Thursday, January 1, 2009, 4:09:39 PM, you wrote:
>>>>
>>>>> Hello Hannes,
>>>>
>>>>> Wednesday, December 31, 2008, 8:33:43 PM, you wrote:
>>>>
>>>>>> On Wed, Dec 31, 2008 at 20:12, Marcus Boerger <helly@php.net>  
>>>>>> wrote:
>>>>>>> Hello Lars,
>>>>>>>
>>>>>>> Wednesday, December 31, 2008, 6:59:08 PM, you wrote:
>>>>>>>
>>>>>>>> Hi Markus,
>>>>>>>
>>>>>>>> have you measured the performance impact in a class with - say -
>>>>>>>> ten
>>>>>>>> methods? And what to do with __get() and __call()? How are the
>>>>>>>> prioritized in the method resolve order?
>>>>>>>
>>>>>>> Translated into user code we now have:
>>>>>>>
>>>>>>> public function __zend_call($name, $args) {
>>>>>>> // Added property lookup
>>>>>>> if (isset($this->$name)) {    // may call __isset
>>>>>>>  $callable = $this->$name;   // may call __get
>>>>
>>>>>> Uhmm. I hope I got this wrong as:
>>>>
>>>>> Well yes, there are no __isset() calls unless you call isset() of
>>>>> course.
>>>>
>>>>> I have updated the patch and added a test to demonstrate it better
>>>>> (closure_036.phpt). I also added debug information to closures
>>>>> which makes
>>>>> development much easier. The next step is to fix an issue in the
>>>>> engine and
>>>>> then submit unless there is a bigger issue with this.
>>>>
>>>>>> class foo {
>>>>>> function __isset() {
>>>>>> return true;
>>>>>> }
>>>>>> function __get() {
>>>>>> return "hello world";
>>>>>> }
>>>>>> function __call() {
>>>>>> }
>>>>>> }
>>>>
>>>>>> $foo = new foo;
>>>>>> $foo->foobar();
>>>>
>>>>>> will first execute __isset(), then __get() and then __call()? That
>>>>>> is
>>>>>> a major backwards compatibility break, and increases the
>>>>>> inconsistency
>>>>>> and decreases readability 10times
>>>>
>>>>>> -Hannes
>>>>
>>>>
>>>>
>>>>
>>>>> Best regards,
>>>>> Marcus
>>>>
>>>>
>>>>
>>>> Best regards,
>>>> Marcus<ze2-callable-properties-5.3-20090101-b.diff.txt>--
>>>> PHP Internals - PHP Runtime Development Mailing List
>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>>
>>
>>
>> Best regards,
>> Marcus<ze2-callable-properties-5.3-20090101-d.diff.txt><ze2-callable- 
>> properties-6.0-20090101-d.diff.txt>--
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php




Best regards,
 Marcus