Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:56033 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 79355 invoked from network); 3 Nov 2011 16:07:46 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Nov 2011 16:07:46 -0000 Authentication-Results: pb1.pair.com smtp.mail=dragoonis@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=dragoonis@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.42 as permitted sender) X-PHP-List-Original-Sender: dragoonis@gmail.com X-Host-Fingerprint: 209.85.216.42 mail-qw0-f42.google.com Received: from [209.85.216.42] ([209.85.216.42:44759] helo=mail-qw0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 6B/54-50864-05CB2BE4 for ; Thu, 03 Nov 2011 11:07:45 -0500 Received: by qadc16 with SMTP id c16so1394617qad.29 for ; Thu, 03 Nov 2011 09:07:41 -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=PM7En8RYV3TW7b0GepgqNFA8HfGZwJpsJ5D+j/o502I=; b=Ue94Opn8dOqnUDEgyPaJq3Hhi/Eiptn400aQDfavU/OTCb1YaJdK0Iv2YBgFNZDyAc m6InAgds+kCf4Jr4jj5jjv4JpxxVJs/2g52B/wcPs1rOw31drNX3fYSl0BassopWR1Y+ jJ7bBLKaA+0rASRllg/Kzvclugsh9c0GV+uVA= MIME-Version: 1.0 Received: by 10.229.66.208 with SMTP id o16mr1269111qci.155.1320336461861; Thu, 03 Nov 2011 09:07:41 -0700 (PDT) Received: by 10.229.83.199 with HTTP; Thu, 3 Nov 2011 09:07:41 -0700 (PDT) In-Reply-To: References: <4E208FE7.4020606@sugarcrm.com> Date: Thu, 3 Nov 2011 16:07:41 +0000 Message-ID: To: PHP Internals List Cc: Anthony Ferrara Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] SplClassLoader From: dragoonis@gmail.com (Paul Dragoonis) On Thu, Nov 3, 2011 at 3: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? =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 mat= ter. 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 would >>> > 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 converted= to a >>> > DIRECTORY_SEPARATOR. >>> There is a internal autoloader in >>> Yaf(http://svn.php.net/viewvc/pecl/yaf/trunk/yaf_loader.c?view=3Dmarkup= ), >>> 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 reduced >> 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 mentioni= ng >> things not part of PSR-0. >> >> But! >> >> The implementation proposal (rfc) should be adjusted to be >> forward compatible, including support for several namespaces pr instance >> (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 would= 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 string >>> > 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 wro= te: >>> >> >> >>> >> >> 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 t= he >>> >> > 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 > >