Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:38493
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain digitalsandwich.com does not designate 72.14.220.158 as permitted sender)
Message-ID: <8d7b8c130806210832i24a1ab2fw6442bb90e0db656a@mail.gmail.com>
Date: Sat, 21 Jun 2008 08:32:16 -0700
To: "PHP Internals List" <internals@lists.php.net>
In-Reply-To: <7495478f0806210829l45b0d8dcw4c610fea8a16da07@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_1392_6907120.1214062336762"
References: <e666c3890806200904i268355ddt1bf6733db15c9699@mail.gmail.com>
	 <485C5081.1050609@zend.com>
	 <7495478f0806210748u1cb4dedcy9b12da02b5ecb4f0@mail.gmail.com>
	 <7495478f0806210829l45b0d8dcw4c610fea8a16da07@mail.gmail.com>
Subject: Re: [PHP-DEV] LSB forward_static_call()
From: m@digitalsandwich.com ("Mike Lively")

------=_Part_1392_6907120.1214062336762
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Fri, Jun 20, 2008 at 5:51 PM, Stanislav Malyshev <stas@zend.com> wrote:
>
> Didn't we discuss that already?


It was discussed but there was never any kind of agreement nor was there
ever any kind of vote. The only reason the discussion stopped is that I
wanted to be sure SOME way of forwarding the called name was in 5.3 core. I
am fairly confident that when it comes right down to it you are in the
minority in this opinion about parent and that combined with the fact that
there was never any kind of vote (that I am aware of) is enough to warrant
bringing up this discussion again.


> Adding magic to parent:: is not a good
> idea, it's very basic language construct and should work simple. LSB is
> an advanced feature, which probably would be used deep inside library guts
> and thus can use more elaborate syntax.
> On top of that, by making parent:: forward called class name, you remove
> the possibility of doing non-forwarding call to the parent class.
>

The possibility is not removed. You can always call the parent class
explicitly. Hell, we could always right a function to call parent methods
without forwarding tihe called class :P.


>
> 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.


I agree with you in that I don't think the speed really matters much in this
case (though maybe I am wrong?). I am looking at this issue purely from the
usability and expectation standpoint.

-Mike Lively

------=_Part_1392_6907120.1214062336762--