Re: [RFC] Re: [PHP-DEV] __invoke() weirdness

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