Re: LSB forward_static_call()

Etienne Kneuss schreef:

Hello, On Sat, Jun 21, 2008 at 2:51 AM, Stanislav Malyshev <stas@zend.com> wrote:

Hi!

So, I really would like to revert that foward_static_call stuff and implement the parent:: patch instead, while it's still possible. thoughts?

Didn't we discuss that already? Adding magic to parent:: is not a good idea, it's very basic language construct and should work simple.

yes!

LSB is an advanced feature, which probably would be used deep inside library guts and thus can use more elaborate syntax.

like static::foo() or if you're really feeling brave fix 'self' so that it does LSB like it 'should' have done from the start.

It seems natural to think of LSB as a language feature, and so it doesn't feel right to have it partly implemented as a keyword, and then fix the problematic part as function. We already see how call_user_func is painful to use (i.e. with methods that use references), that same burden will be put on forward_static_call.

and ironically call_user_func*() is quite often used in hacks that work round the lack of LSB. forward_static_call() would relegate LSB to a second rate feature, whilst 'comparable' languages treat it as a core OO feature. I know that other languages are not the measure of things, but in the case of LSB I believe it should be a first class feature of an OO language.

On top of that, by making parent:: forward called class name, you remove the possibility of doing non-forwarding call to the parent class.

Why would that be no longer possible ? If you want to make a non-forwarding call to the parent class, you can use TheParentClassName::foo();.

I certainly don't expect 'parent' to end up making a call to a method defined in a sub-class. Also don't we use 'parent' for much the same reason we use '__construct' ? i.e. so we don't need to know which class is actually the parent defining the requested method. rewriting parent::meth() into parentClassName::meth() is like rewriting class Foo {function __construct() {}} into class Foo {function Foo() {}} no? please reconsider a either a new explicit keyword (e.g. 'static') or even making 'self' LSB. I doubt much code would be affected if the semantics of 'self' changed. another possibility is the keyword 'child', fits in nicely with 'parent' and 'self' and describes nicely where in the class hierarchy a search for the method/property will begin.

As for it being slow - how slow it is? Does it really so slow that it makes real-life application that otherwise would be fast to be slow? Or it's just "couple more CPU cycles" slow? I suspect the latter - and thus I don't think speed optimizations belong there.

It's about 85% slower than a direct call. Sure it's not that slow when measuring absolutely, but we're talking about a feature that will be typically used in frameworks and libraries, so the amount of calls may be quite big.

-- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com