Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:68897 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 97191 invoked from network); 5 Sep 2013 10:32:34 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Sep 2013 10:32:34 -0000 Authentication-Results: pb1.pair.com header.from=pierre.php@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=pierre.php@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.43 as permitted sender) X-PHP-List-Original-Sender: pierre.php@gmail.com X-Host-Fingerprint: 209.85.215.43 mail-la0-f43.google.com Received: from [209.85.215.43] ([209.85.215.43:33935] helo=mail-la0-f43.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 37/DB-01925-0CD58225 for ; Thu, 05 Sep 2013 06:32:33 -0400 Received: by mail-la0-f43.google.com with SMTP id ep20so1396725lab.16 for ; Thu, 05 Sep 2013 03:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=82fFX9dLBuJQG2Ub2PSsIU26t2oRUV48EmYdu8yFyfM=; b=CxnMJAyyrz6Ea8b2ISOoq/23vcRvc7+Y9VZQnLAYPxgrTk6sh1q1BgRegzRMPKVx8Y cb/Ga1Nhh77wKE1BGEKzJKcLpLVw/bWUlHNeQvZUSu4/voPt9d0tDiK1dlFGEjFt5Xbk 29cSUpyWpp+iM6kMO0qnRvryHEFdaYv+TCkJ7H7Rn9jr2JD5vMrsM15zfU+pBifCA6ju mjjoU08162rePCEO3LMj3NorMXAKdUZD2c7i9348UbzasuhX13SGon++F5xJkUHPMacG NcruMwI5Y2bMOe3neVcLcMBa/ejuoLT8JzpblZ0uvasWJqI7bOFgP94dmz55kZoMH2+3 e+nw== MIME-Version: 1.0 X-Received: by 10.152.120.5 with SMTP id ky5mr6947177lab.18.1378377148795; Thu, 05 Sep 2013 03:32:28 -0700 (PDT) Received: by 10.112.148.138 with HTTP; Thu, 5 Sep 2013 03:32:28 -0700 (PDT) In-Reply-To: References: <5220D212.3010101@sugarcrm.com> <61FCD6C4A31248078FEAD2BA73D7CD44@gmail.com> <7AF31CC1D1554454AC95AE758D23E92E@gmail.com> <52243F6C.7070806@sugarcrm.com> <5224EEEF.3070204@sugarcrm.com> <52250E8F.5010805@sugarcrm.com> Date: Thu, 5 Sep 2013 12:32:28 +0200 Message-ID: To: Nikita Popov Cc: Sebastian Krebs , Levi Morrison , Stas Malyshev , Anthony Ferrara , Nicolas Grekas , "internals@lists.php.net" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [PHP-DEV] Re: Function autoloading From: pierre.php@gmail.com (Pierre Joye) On Thu, Sep 5, 2013 at 11:34 AM, Nikita Popov wrote: > On Thu, Sep 5, 2013 at 10:51 AM, Pierre Joye wrote: >> >> On Thu, Sep 5, 2013 at 10:23 AM, Sebastian Krebs >> wrote: >> >> >> > That being said, there is always a point in a RFC discussion where >> >> > there is nothing left to discuss or argue about, we are so far with >> >> > this one. >> >> >> >> >> >> We've been at this point for a while; no new arguments have been raised >> >> despite several people asking to bring it back in focus. >> >> I totally understand your view on how such discussions go. However it >> was (for what I read) about technical issues and the tones were >> correct, could have been more diplomatic but that's fine imho. I am >> not sure how to solve this problem as we have to discuss things deeply >> and be sure that active core developers actually understand all the >> impact of a given proposal will have, that's a must. > > > I don't think this discussion was about technical issues. Let me summarize > the main discussion points: > > * "This will make function calls slower!". Many complaints about this > change hurting performance, even though it was pointed out early on (and > detailed in the RFC) that this is not true. > * "Will you put every function in it's own file?!". This has been repeated > *a lot* in this thread, even though again it has been pointed out early that > there are more reasonable autoloading schemes for functions (e.g. > namespace-to-file) > * "Just use static methods instead". I don't need to comment on the > absurdity of this statement. > * "Which function is autoloaded?" Is the namespaced version or the global > fallback loaded? > > Of these, only the last point has been of any benefit to this discussion. > There has also been some minor discussion regarding the API, which is also > relevant. But why does 80% of this thread deal with performance (known > incorrect assumption), unreasonable suggestions of function-to-file mappings > (even though alternatives are known) and suggestions to just not use > functions? It's really hard to fish out the 10 relevant mails in a > discussion spanning 70 in total. Right, it goes circular way too often. I see that in many other MLs. I however do not see it as a reason to leave, no matter how much it happens. I also see these questions, discussions or arguing session as technical matters, be semantic, common sense or anything else. It is all about being sure about what php will be after a given feature is added. > I'm pretty sure that Anthony's reaction is not directly related to this > particular thread - rather it is an accumulation of the very same kind of > discussion we have on nearly every RFC. Discussion is always very circular, > covering issues that have already been addressed (usually even written down > in the RFCs). Typically this kind of pointless discussion happens between > just three or so people and fills the largest part of the thread. Stas is > usually one of those "three" people, though of course I will not imply > causation from correlation. I very much respect Stas, both for his constructive attitude and the insane amount of work he puts in PHP and the related projects. As anyone else, he is however a human, with needs to understand a specific point very clearly. I do not think there any evil or domination behavior here. About the N people trying to control everything, that's why we have RFCs. Maybe we should scan discussions more frequently and stop them when it goes circular, ask to update the RFC accordingly and move forward. This is something I tried to do. Sadly I was busy with other stuff in the last couple of months and was not able to follow each recent RFC discussions closely. Cheers, -- Pierre @pierrejoye | http://www.libgd.org