Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:38539 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 70792 invoked from network); 23 Jun 2008 13:36:12 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Jun 2008 13:36:12 -0000 Authentication-Results: pb1.pair.com header.from=m@digitalsandwich.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=m@digitalsandwich.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain digitalsandwich.com from 64.233.170.189 cause and error) X-PHP-List-Original-Sender: m@digitalsandwich.com X-Host-Fingerprint: 64.233.170.189 rn-out-0910.google.com Received: from [64.233.170.189] ([64.233.170.189:60684] helo=rn-out-0910.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 90/2E-23032-AC6AF584 for ; Mon, 23 Jun 2008 09:36:11 -0400 Received: by rn-out-0910.google.com with SMTP id k40so270766rnd.0 for ; Mon, 23 Jun 2008 06:36:08 -0700 (PDT) Received: by 10.142.11.2 with SMTP id 2mr3767885wfk.1.1214228168148; Mon, 23 Jun 2008 06:36:08 -0700 (PDT) Received: by 10.142.238.4 with HTTP; Mon, 23 Jun 2008 06:36:08 -0700 (PDT) Message-ID: <8d7b8c130806230636w5c441391xb374a23eb579c0e7@mail.gmail.com> Date: Mon, 23 Jun 2008 06:36:08 -0700 To: "Jochem Maas" Cc: "Etienne Kneuss" , "Stanislav Malyshev" , "PHP internals" In-Reply-To: <485F69E1.6060907@iamjochem.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_12619_28302574.1214228168138" References: <485C5081.1050609@zend.com> <485ED5E5.1050904@iamjochem.com> <485F69E1.6060907@iamjochem.com> Subject: Re: [PHP-DEV] LSB forward_static_call() From: m@digitalsandwich.com ("Mike Lively") ------=_Part_12619_28302574.1214228168138 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, Jun 23, 2008 at 2:16 AM, Jochem Maas wrote: > 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. > The behavior of the parent:: as it relates to "existing" code is not changing. The only change of behavior is as it relates to the usage of static:: when parent:: is called on a method. That is why making this decision is now. Once 5.3 is released the behavior of parent:: will be locked in much the same way self:: was in 5.0 > > 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::? > static:: has been implemented for quite some time and the reason why forward_static_call was created and the reason why we want to change parent:: have been discussed at some length on this list. I'm mildly suprised you haven't seen it. Try reading: http://www.digitalsandwich.com/archives/65-Late-static-binding....sorta.htmlIt gives a pretty good description of what I disagreed with in the current patch. Then http://www.ds-o.com/archives/68-Late-Static-Binding-Changes-to-parent.htmlintroduces three patches to potentially resolve my issues. The three patches are really standalone (save a mistake I made when creating the forwarding patch that caused me to include forward_static_call()). forward_static_call patch has been implemented already. While this addresses my concerns I think it does so in a far less than optimal way. The first patch is what Etienne is talking about implementing which I am totally in favor for. The second patch is really is the same as the first, it just introduces a new keyword (which I do not think is needed.) ------=_Part_12619_28302574.1214228168138--