Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42442
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain bitextender.com from 80.237.132.12 cause and error)
To: Marcus Boerger <helly@php.net>
In-Reply-To: <886533446.20090101175039@marcus-boerger.de>
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>
Message-ID: <A2475678-E055-4C0E-BBAA-B6A59C45E36F@bitextender.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Fri, 2 Jan 2009 08:03:22 +0100
Cc: "Hannes Magnusson" <hannes.magnusson@gmail.com>,
 "Lars Strojny" <lstrojny@php.net>,
 "PHP Internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Re: [PHP-DEV] __invoke() weirdness
From: david.zuelke@bitextender.com (=?ISO-8859-1?Q?David_Z=FClke?=)

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.

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