On Thu, Nov 3, 2011 at 7:30 PM, Anthony Ferrara <ircmax...@gmail.com> wrote:
> 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 > I've tried to stay out of the discussion and have successfully done so. Until today. I feel that there's something that's been missing to the discussion. There is nothing missing in this discussion Anthony, you should have tried harder.. ;) > Recently there has been a rather heated and intense discussion on (...) That is php internals in a nutshell, not a good thing indeed but not specific to this thread. > Issue #1 - It is inconsistent Being that the only argument here is case sensitivity: Imho PSR-0 is very consistent. If you use lowerCamelCase on the class names or your namespace, it will (/should) be exactly like on disk as well. (and yes, I'm aware of some file system being case insensitive, but they are not used in production) > Issue #2 - It is not a standard You are partly right on this one, but someone might argue that it is a de facto standard as it is picking up steam in all major frameworks (of importance). Which might be a clear sign that the php community wants more widespread standards, conventions and collaboration. > Issue #3 - There's nothing for the core to gain This will not be forced on anyone. It will be a more modern alternative to http://www.php.net/manual/en/function.spl-autoload.php So yes, there is already something like this in core, so I really don't get why you are so against this, not seeing the wood for the trees? :) > > > 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 > >
