Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:38555
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.170.187 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references:x-google-sender-auth;
        b=c6rICJrZslfpiAAXT3Xq7F3WKd27awJy8V4JES95tTfie2nppQmNZxyoMo22dkASj9
         GyjXphpI57TQMJOdTa4pM84fykHO4tl63rXNmdjL9Z6CPSsNppL35aF8sFjM5zuPPioY
         YkuFWiuJpuJ7IapyJqXAAl0LdJ2Ct8koHCtTg=
Message-ID: <e666c3890806231146o6da37a9dq44483e1e9bce844a@mail.gmail.com>
Date: Mon, 23 Jun 2008 20:46:57 +0200
Sender: ekneuss@gmail.com
To: "Stanislav Malyshev" <stas@zend.com>
Cc: "PHP internals" <internals@lists.php.net>
In-Reply-To: <485FD5E5.6070002@zend.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <e666c3890806200904i268355ddt1bf6733db15c9699@mail.gmail.com>
	 <485C5081.1050609@zend.com>
	 <e666c3890806210158p306f0448p263eecc6cd2f1d0f@mail.gmail.com>
	 <485FD5E5.6070002@zend.com>
Subject: Re: [PHP-DEV] LSB forward_static_call()
From: colder@php.net ("Etienne Kneuss")

Hello,

On Mon, Jun 23, 2008 at 6:57 PM, Stanislav Malyshev <stas@zend.com> wrote:
> Hi!
>
>> 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.
>
> There's nothing wrong with functions - call_user_* are functions too, and
> func_get_args(), etc.

Sure, there are nothing wrong with functions, my point is that LSB is
implemented partly with a keyword and partly with a function. Which is
IMO a bad idea. Why use static:: in the first place ? We could have
used call_called_class_method("method"), oh right: it's ugly as hell.

>
>> 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.
>
> If we have problem with using call_user_* with references, that should be
> fixed (do we have description of what exactly is missing - like bug report
> or RFC or something?) But it won't be fixed by changing parent::, so how
> it's relevant here?

sure, the "fix" is
$args = array($byval, &$byref);
forward_static_call_array(array('parent', 'foo'), $args);
instead of:
parent::foo($byval, $byref);

I guess its quite obvious to see which way will be prefered.

>
>> 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();.
>
> Why having parent:: at all then? You could always use the class name, right?
> But for some reason we do have parent:: - and that reason is that using
> explicit class name is not a good style in this context, it both obscures
> the intent and makes unnecessary dependencies in the code. Now imagine on
> top of that we have name:: and parent:: work differently, so you don't have
> choice but using name:: for certain things.

yes parent:: is convenient, that's why it's there.

Here is the possible scenarios:
1) you don't use any LSB in your static method => you use parent::
without caring
2) you use LSB in the method of the parent class, and you need to
overwrite that static method, but still call it from the child method,
2.1) you use parent:: as usual
2.2) you need to lie to the parent class by telling that the method
was directly called.

Now, 2.1 seems to be oviously more frequent than 2.2. I can't even
think of a decent reason to need 2.2 (do you have any example of
"certain things" ?). Which means that when the difference between
parent:: and ParentClassName:: is relevant, parent:: will be used more
often.

Additionally, forward_static_call allows to do calls to unrelated
methods, (without passing the caller info) which increases the WTF
factor. parent::foo on the other hand is well defined.

>
>> 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.
>
> I do not think extra CPU instruction or two is really the factor here. We
> are talking about high-level language, not assembly language.
> --
> Stanislav Malyshev, Zend Software Architect
> stas@zend.com   http://www.zend.com/
> (408)253-8829   MSN: stas@zend.com
>
>



-- 
Etienne Kneuss
http://www.colder.ch

Men never do evil so completely and cheerfully as
when they do it from a religious conviction.
-- Pascal