Etienne Kneuss schreef:
Hello,
On Mon, Jun 23, 2008 at 12:44 AM, Jochem Maas <[EMAIL PROTECTED]> wrote:
Etienne Kneuss schreef:
Hello,
On Sat, Jun 21, 2008 at 2:51 AM, Stanislav Malyshev <[EMAIL PROTECTED]> 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.
changing self:: is not an option as it would break BC.
and the same is not true of parent::? besides which I doubt any same code
would actually break if the semantics of self:: changed, much less than
if parent:: changed at any rate.
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?
not really, for now, parent is simply an alias of the parent class.
but certainly not an alias for any child class.
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.
static::foo() is already implemented in HEAD and 5_3, it references
the class found with runtime information.
child is not a good keyword as LSB may not be to the direct child, it
can go through multiple childs in the inheritance branch, or it can
also reference the current class if no fallbacks occurred.
I understand that, the same is true for self:: and parent:: in that they
go though multiple ancestors (starting at the current class for self::) in
the anscetral inheritance branch, so I find the argument against 'child' weak,
but at the same time not important. I can live with anyname one cares to give
it.
Is this whole discussion pointless? given that you say 'static' has already been
implemented ... doesn't that negate the requirement for forward_static_call()
and
also the need to repurpose parent::?
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
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
