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 <dragoo...@gmail.com> wrote: > On Thu, Nov 3, 2011 at 3:19 PM, Anthony Ferrara <ircmax...@gmail.com> 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... >> >> 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 > matter. > > Regards, > Paul Dragoonis. > >> >> >> On Thu, Nov 3, 2011 at 10:56 AM, André Rømcke <a...@ez.no> wrote: >>> On Thu, Oct 27, 2011 at 4:30 AM, Laruence <larue...@php.net> wrote: >>> >>>> 2011/10/26 André Rømcke <a...@ez.no>: >>>> > On Tue, Oct 25, 2011 at 4:39 AM, guilhermebla...@gmail.com < >>>> > guilhermebla...@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 “_” character in the CLASS NAME is converted to a >>>> > DIRECTORY_SEPARATOR. The “_” character has no special meaning in the >>>> > namespace. >>>> > >>>> > is changed to >>>> > * Each “_” 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=markup), >>>> 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 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 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' => '/path/to/doctrine' ) ); >>> >>> >>> Or something like this (if we want the options to be an array): >>> >>> new SplClassLoader( array( 'ns' => array( 'Doctrine\Common' => >>> '/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 <dav...@php.net> 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: guilhermebla...@hotmail.com >>>> >> São 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/ >>>> >>> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
