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 <he...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
