Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:38526 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 44031 invoked from network); 23 Jun 2008 00:05:55 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Jun 2008 00:05:55 -0000 Authentication-Results: pb1.pair.com header.from=ekneuss@gmail.com; sender-id=pass; domainkeys=bad Authentication-Results: pb1.pair.com smtp.mail=ekneuss@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.132.244 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: ekneuss@gmail.com X-Host-Fingerprint: 209.85.132.244 an-out-0708.google.com Received: from [209.85.132.244] ([209.85.132.244:11676] helo=an-out-0708.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A8/99-23032-1E8EE584 for ; Sun, 22 Jun 2008 20:05:54 -0400 Received: by an-out-0708.google.com with SMTP id c14so463555anc.1 for ; Sun, 22 Jun 2008 17:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received: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; bh=t4X6hzK87xCKjrRlxOGtcQ0xxKCAzY4VNQOq1rXQBCc=; b=qrBVBuWW/ZZhKQd3H9o5Q8miVhC8Q/tSnYFzWvZ+wQ2y2G2l7fAAc56tK7WUi5Me0N L8Wr3SD6UBvMa62JPQgcyiuGKLaUa5WeID5/Ox6zdZs6iL+sTVYuMDBz4u8SPLYxU+XC A32BqCN9kI5aDLYhruwOt0W/n6xoagT8FasUU= 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=vjF3C5ACGcNGJWgXx6gPOL6iYab1UqPvirhep+WTsCZ474ZwjOaFh0GbWB/eA0Td4m 1OuglWg+yebpriTz+dQT7bT13XpVddaiDFrZUnF1JiNuiWdm+RVPzo1psoCqhn2vBwHM FYeluNRWlDmhT/2WPqCsJP5x4tt7xrVgiZqAU= Received: by 10.100.178.13 with SMTP id a13mr11823374anf.29.1214179550590; Sun, 22 Jun 2008 17:05:50 -0700 (PDT) Received: by 10.151.83.19 with HTTP; Sun, 22 Jun 2008 17:05:45 -0700 (PDT) Message-ID: Date: Mon, 23 Jun 2008 02:05:45 +0200 Sender: ekneuss@gmail.com To: "Jochem Maas" Cc: "Stanislav Malyshev" , "PHP internals" In-Reply-To: <485ED5E5.1050904@iamjochem.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <485C5081.1050609@zend.com> <485ED5E5.1050904@iamjochem.com> X-Google-Sender-Auth: 6dc59d1a35d9e295 Subject: Re: [PHP-DEV] LSB forward_static_call() From: colder@php.net ("Etienne Kneuss") Hello, On Mon, Jun 23, 2008 at 12:44 AM, Jochem Maas wrote: > Etienne Kneuss schreef: >> >> Hello, >> >> On Sat, Jun 21, 2008 at 2:51 AM, Stanislav Malyshev 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. > >> >> 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. > > 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. > >> >>> 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 >>> 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