Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:56040 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 97398 invoked from network); 3 Nov 2011 18:30:35 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Nov 2011 18:30:35 -0000 Authentication-Results: pb1.pair.com header.from=ircmaxell@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=ircmaxell@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender) X-PHP-List-Original-Sender: ircmaxell@gmail.com X-Host-Fingerprint: 209.85.216.170 mail-qy0-f170.google.com Received: from [209.85.216.170] ([209.85.216.170:62457] helo=mail-qy0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2C/67-50864-9CDD2BE4 for ; Thu, 03 Nov 2011 13:30:34 -0500 Received: by qyg14 with SMTP id 14so30312qyg.8 for ; Thu, 03 Nov 2011 11:30:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Y4H8Q0syiuOEmSvxEopUAMuCW6b5hDr3sl1798JKNnI=; b=c2DShpS2D0dFgtJyDYvk8PnrMESEWNaxob77JS3X93gRUpOKzPvZ6boW0r/tXvQ8vR pmzVYd/fUN6n+8XhjCfOXPvAwNK8joKhVh9mWxVEXPH4sCbi+ild3JBhzkgj2L9TjwTY P1wUV7qTi3zOD8ehCP7SeeMxRoA1CXRdtsH1A= MIME-Version: 1.0 Received: by 10.229.68.41 with SMTP id t41mr1360806qci.279.1320345028571; Thu, 03 Nov 2011 11:30:28 -0700 (PDT) Received: by 10.229.6.202 with HTTP; Thu, 3 Nov 2011 11:30:28 -0700 (PDT) In-Reply-To: References: <4E208FE7.4020606@sugarcrm.com> Date: Thu, 3 Nov 2011 14:30:28 -0400 Message-ID: To: Paul Dragoonis Cc: PHP Internals List Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] SplClassLoader From: ircmaxell@gmail.com (Anthony Ferrara) Paul, I wasn't saying whether it should be included or not. I was saying that performance should not be a justification for it being included. It may be a benefit, but it's a very small side benefit as opposed to a primary one. Additionally, I wholeheartedly disagree with one of your points there: > With the point to being included in /ext/spl/; is to give a sense of > "justification" of this standard and a base in which to push forward. I was going to write a long rebuttal to the whole concept here, but I realized that wouldn't really be a good thing for the list. So I put it in a blog post as it's more of a personal opinion... http://blog.ircmaxell.com/2011/11/on-psr-0-being-included-in-phps-core.html Anthony On Thu, Nov 3, 2011 at 12:07 PM, Paul Dragoonis wrote= : > On Thu, Nov 3, 2011 at 3:19 PM, Anthony Ferrara wro= te: >> Can I make a point here. >> >> Why the heck are we caring about the performance of the autoloader at >> all here? =A0The filesystem operations necessary (at least the stat() >> call) will greatly dominate any string function. =A0And considering that >> even the biggest framework only has perhaps a few hundred classes, >> you're talking about incredibly small performance gains here. =A0Even 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. =A0It'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. =A0We're talking about implementing a >> function which already is dominated by non-computational overhead into >> C to save a few milliseconds. =A0The number of instances that will >> benefit from such an addition are incredibly small. =A0Saving 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. =A0And those that do benefit >> would have access to their server farm to add the pecl extension >> anyway. =A0So 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. =A0I just want to emphasize the point that >> performance should not be a criteria for justifying it going into the >> core... >> >> Anthony > Basically, theres approx a dozen of the most recognised PHP libraries > that are advocating the use of a generalised class mapping standard. > > This is great, and allows switching between projects very seamless as > there's no additional learning curve. > while(consistency) learning_curve--; > > If library vendors are implementing their own custom autoloading > structure/mechanism it's very counter-productive to the PHP > eco-system. The point of PSR-0 is to create a standard to allow > compatibility between vendor libs such as ZF/Symfony/PPI. > > With the point to being included in /ext/spl/; is to give a sense of > "justification" of this standard and a base in which to push forward. > It's also giving existing lib vendors to easily switch to a well-built > autoloading mechanism bundled with PHP rather than relying on > third-party code to provide that. Additionally the small performance > boost but including SplClassLoader is not driven by the speed benefit > but by the community/library benefit. > > This appears to be the general consensus of PSR-0 and my opinion on the m= atter. > > Regards, > Paul Dragoonis. > >> >> >> On Thu, Nov 3, 2011 at 10:56 AM, Andr=E9 R=F8mcke wrote: >>> On Thu, Oct 27, 2011 at 4:30 AM, Laruence wrote: >>> >>>> 2011/10/26 Andr=E9 R=F8mcke : >>>> > 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 =93_=94 character in the CLASS NAME is converted to a >>>> > DIRECTORY_SEPARATOR. The =93_=94 character has no special meaning in= the >>>> > namespace. >>>> > >>>> > is changed to >>>> > * Each =93_=94 character in the CLASS NAME and NAMESPACE is converte= d 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 mention= ing >>> 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 wr= ote: >>>> >> >> >>>> >> >> Could you open a FR at bugs.php.net and attach the patch to it >>>> please? >>>> >> >> Could be easier to track =A0(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=E3o Paulo - SP/Brazil >>>> >> >>>> >> -- >>>> >> PHP Internals - PHP Runtime Development Mailing List >>>> >> To unsubscribe, visit: http://www.php.net/unsub.php >>>> >> >>>> >> >>>> > >>>> >>>> >>>> >>>> -- >>>> Laruence =A0Xinchen Hui >>>> http://www.laruence.com/ >>>> >>> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> >