Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:38475
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 66.249.92.170 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:mime-version:content-type
         :content-transfer-encoding:content-disposition:x-google-sender-auth;
        b=M6F2feuKYmDl15pF92A+AUbfrR1yALagIk+WqWnOdkA8ue2oUfynLHHzTvk5lITQVe
         x091KiaB7/hiuA2r76iUdRCHcC/LWR05GG3rY7whI9lAFn3RRQ+9kz9zsGS3IFLdot4z
         kyR4buxbOWi2MeYNAiQoeihhsETP8l3WbJeIM=
Message-ID: <e666c3890806200904i268355ddt1bf6733db15c9699@mail.gmail.com>
Date: Fri, 20 Jun 2008 18:04:13 +0200
Sender: ekneuss@gmail.com
To: "PHP internals" <internals@lists.php.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: LSB forward_static_call()
From: colder@php.net ("Etienne Kneuss")

Hi,

Sorry to bring that up again!

Quick summary for people that didn't follow it: LSB was implemented,
and it was decided that "explicit calls" ( ClassName::method() )
wouldn't pass the caller info if no fallbacks occured. Some people
that were looking forward to having LSB were disappointed as it meant
that it wouldn't be possible to sanely overwrite a static method,
without loosing info on the caller.

Quick POC:
class A { public static function test() { echo get_called_class(); }}
class B extends A { public static function test() { echo
get_called_class(); parent::test(); }
class C extends B;
C::test(); // will output CA

To be able to pass information, it was decided to implement a
call_user_func-like function that passed the caller info:
forward_static_call(_array).

Back then, I was for that solution, but with some time I realized that
it would probably be one of those decisions that would bite us back
afterward.

To sum up key points about each possibilities:

1) forward_static_call
+ no need to affect the engine
- slow, painful

2) parent:: carries the info while ParentClassName:: doesn't
+ convenient
+ no functionnality lost
- introduces a difference between parent:: and classname::, but
restricted to LSB so no BC break

It really seems like (2) is the most PHP way of doing things, while
(1) is more of a hack that we will regret later.
The only problem about (2) is that difference, but I really feel (and
experienced in the multiple help channels that I'm in) that people
already see (wrongly for now) classname:: and parent:: as slightly
different. So introducing it as of 5_3 wouldn't be too much of a
shock. The point is that: people who uses LSB will be aware of that
difference and will use parent:: vs classname:: carefully, while
others will be able to ignore it

So, I really would like to revert that foward_static_call stuff and
implement the parent:: patch instead, while it's still possible.

thoughts?

-- 
Etienne Kneuss
http://www.colder.ch

Men never do evil so completely and cheerfully as
when they do it from a religious conviction.
-- Pascal