Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:56032 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 77381 invoked from network); 3 Nov 2011 15:57:18 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Nov 2011 15:57:18 -0000 Authentication-Results: pb1.pair.com header.from=ar@ez.no; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=ar@ez.no; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain ez.no from 209.85.210.170 cause and error) X-PHP-List-Original-Sender: ar@ez.no X-Host-Fingerprint: 209.85.210.170 mail-iy0-f170.google.com Received: from [209.85.210.170] ([209.85.210.170:36936] helo=mail-iy0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 6A/04-50864-CD9B2BE4 for ; Thu, 03 Nov 2011 10:57:17 -0500 Received: by iakc1 with SMTP id c1so1679929iak.29 for ; Thu, 03 Nov 2011 08:57:14 -0700 (PDT) Received: by 10.43.44.199 with SMTP id uh7mr9067048icb.25.1320335833471; Thu, 03 Nov 2011 08:57:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.158.2 with HTTP; Thu, 3 Nov 2011 08:56:51 -0700 (PDT) In-Reply-To: References: <4E208FE7.4020606@sugarcrm.com> Date: Thu, 3 Nov 2011 16:56:51 +0100 Message-ID: To: Anthony Ferrara Cc: Laruence , "guilhermeblanco@gmail.com" , David Coallier , Pierre Joye , Mike Willbanks , PHP Internals List Content-Type: multipart/alternative; boundary=bcaec52999eb569c2204b0d6a4a5 Subject: Re: [PHP-DEV] SplClassLoader From: ar@ez.no (=?UTF-8?B?QW5kcsOpIFLDuG1ja2U=?=) --bcaec52999eb569c2204b0d6a4a5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Nov 3, 2011 at 4:19 PM, Anthony Ferrara wrote= : > Can I make a point here. > > Why the heck are we caring about the performance of the autoloader at > all here? The filesystem operations necessary (at least the stat() > call) will greatly dominate any string function. And considering that > even the biggest framework only has perhaps a few hundred classes, > you're talking about incredibly small performance gains here. Even if > you save a microsecond in string operations (try it, even in PHP the > string operations can be done in around 10 or 20 microseconds), after > all classes are loaded you're only talking about a 1 or 2 milliseconds > of gain in the application. > > I'm not saying that we shouldn't try to save time where we can, but > given the controversial nature of this addition, I don't think that a > micro-optimization (which is what this really is) should be used as a > justification for why it should be included. It's not like we're > talking about implementing a computationally difficult task into C > (such as a cryptographic algorithm) where putting it into C would > create a huge performance gain. We're talking about implementing a > function which already is dominated by non-computational overhead into > C to save a few milliseconds. The number of instances that will > benefit from such an addition are incredibly small. Saving 2 > milliseconds on an application (that likely takes hundreds of > milliseconds to render) would require a huge number of requests to > amortize into an actual measurable benefit. And those that do benefit > would have access to their server farm to add the pecl extension > anyway. So there's really no practical performance gain to the > community as a whole, hence confirming that this is a > micro-optimization. > > Personally I feel that this does not belong in the core (especially > not yet as with the inconsistencies). > > But that's besides the point. I just want to emphasize the point that > performance should not be a criteria for justifying it going into the > core... You mixing up one of my personal objectives* with the poster's objective** (which I also share). * making the class map based vs convention based performance discussion moot, making sure more people will standardize around PSR-0 ** making sure there is a autoloader in php that follows a convention that people actually use, and further standardized how such a basic thing is done in php projects in the wild. > > > > On Thu, Nov 3, 2011 at 10:56 AM, Andr=C3=A9 R=C3=B8mcke wrote: > > On Thu, Oct 27, 2011 at 4:30 AM, Laruence wrote: > > > >> 2011/10/26 Andr=C3=A9 R=C3=B8mcke : > >> > On Tue, Oct 25, 2011 at 4:39 AM, guilhermeblanco@gmail.com < > >> > guilhermeblanco@gmail.com> wrote: > >> > > >> >> Hi internals, > >> >> > >> >> For all those interested, I have updated the RFC with better > >> >> explanation, included example implementation and also example usage= . > >> >> If you have any other wishes, doubts, etc, feel free to ask on this > >> >> thread and I'll quickly answer here and also update the RFC > >> >> accordingly. > >> >> > >> > > >> > > >> > As sent to the PHP-SWG list, a small change / addition to PSR-0 woul= d > >> > simplify the matching considerably. > >> > > >> > If this rule: > >> > * Each =E2=80=9C_=E2=80=9D character in the CLASS NAME is converted = to a > >> > DIRECTORY_SEPARATOR. The =E2=80=9C_=E2=80=9D character has no specia= l meaning in the > >> > namespace. > >> > > >> > is changed to > >> > * Each =E2=80=9C_=E2=80=9D character in the CLASS NAME and NAMESPACE= is converted to a > >> > DIRECTORY_SEPARATOR. > >> There is a internal autoloader in > >> Yaf(http://svn.php.net/viewvc/pecl/yaf/trunk/yaf_loader.c?view=3Dmarku= p), > >> in it the T_NS_SEPARATOR will convert to be "_", then convert to be > >> DIRECTORY_SEPARATOR. > >> > >> thanks > >> > > > > > > As mentioned by others this will have to go into a new PSR standard as > > PSR-0 was accepted 2 years ago. > > > > And assuming that a C implementation will greatly out-weight the reduce= d > > amount of str functions in terms performance we should not block this > > process to get it into 5.4 by taking up off-topic subjects like > mentioning > > things not part of PSR-0. > > > > But! > > > > The implementation proposal (rfc) should be adjusted to be > > forward compatible, including support for several namespaces pr instanc= e > > (mention by several on PSR mailing list) imho. > > > > Possible example (additional arguments can be added later when more > > features are added, aka a PSR-1 mode): > > > > new SplClassLoader( array( 'Doctrine\Common' =3D> '/path/to/doctrine' )= ); > > > > > > Or something like this (if we want the options to be an array): > > > > new SplClassLoader( array( 'ns' =3D> array( 'Doctrine\Common' =3D> > > '/path/to/doctrine' ) ) ); > > > > > > For documentation and argument validation, imo the former approach woul= d > be > > better. > > So what is the status here? thread has been silent for a while. > > > > > >> > > >> > Or a strict mode is added to enable that, then you'll reduce 6 strin= g > >> > function to 2, and still have backward support for PEAR class > naming(w/o > >> > namespace). > >> > > >> > > >> > > >> > > >> >> The url for the RFC is: https://wiki.php.net/rfc/splclassloader > >> >> > >> >> Cheers, > >> >> > >> >> On Mon, Oct 24, 2011 at 7:55 PM, David Coallier > wrote: > >> >> >> > >> >> >> Could you open a FR at bugs.php.net and attach the patch to it > >> please? > >> >> >> Could be easier to track (and the # to the RFC too :) > >> >> >> > >> >> > > >> >> > Yeah I'll do that once I have the tests adjusted and once I know > the > >> >> > patch actually works as expected. > >> >> > > >> >> > -- > >> >> > David Coallier > >> >> > > >> >> > -- > >> >> > PHP Internals - PHP Runtime Development Mailing List > >> >> > To unsubscribe, visit: http://www.php.net/unsub.php > >> >> > > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> Guilherme Blanco > >> >> Mobile: +55 (11) 8118-4422 > >> >> MSN: guilhermeblanco@hotmail.com > >> >> S=C3=A3o Paulo - SP/Brazil > >> >> > >> >> -- > >> >> PHP Internals - PHP Runtime Development Mailing List > >> >> To unsubscribe, visit: http://www.php.net/unsub.php > >> >> > >> >> > >> > > >> > >> > >> > >> -- > >> Laruence Xinchen Hui > >> http://www.laruence.com/ > >> > > > --bcaec52999eb569c2204b0d6a4a5--