On Fri, Nov 4, 2011 at 10:33 AM, André Rømcke <a...@ez.no> wrote: > 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? :)
did you read the blogpost? most of your replies were cowered there. "If you use lowerCamelCase on the class names or your namespace, it will (/should) be exactly like on disk as well." it is "consistent" between the class to file mapping, but the fact that it doesn't care about the underlying fs, or the fact that the classnames are case insensitive in php. which could create problems, like the following code would work: new \Foo; new \foo; but this would not: while new \foo; new \Foo; if the file for that class is 'Foo.php' I think Antony referred to this behavior as inconsistent. "(and yes, I'm aware of some file system being case insensitive, but they are not used in production)" uhm, windows? and as I explained the mentioned inconsistency is when you use a case sensitive FS. "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." I think that this was pretty much answered/cowered in Anthonys blogpost and the other post that he linked: http://gooh.posterous.com/why-the-psr-0-classloader-does-not-belong-int Generally speaking: - a common class loader is a nice thing to have, everybody agrees on that. - but the PSR-0 was created by and for a small subset of the php community(framework people). - php core doesn't force/favor any coding convention/standard, why should it do it for PSR-0? "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? :)" first of all, I found your wording a little bit offensive (here and also in the "you should have tried harder.. ;)"), but to get to the point, this was also cowered in the linked blogpost ( http://gooh.posterous.com/why-the-psr-0-classloader-does-not-belong-int): "To stress this, I am not against having a native classloader. But I am against putting it into SPL when it requires PSR-0. No other function in PHP requires us to use a certain code convention. The argument that it is optional doesn’t count. It is not a general purpose classloader when I have to follow PSR-0 for it and thus it shouldn’t be in SPL." My personal opinion on the matter: - Obviously I also think that having a common autoloader between my components/libs is a good step forward. - I don't really see that what is the point in having this in the core (as it was pointed out the performance gain would be negligible, as the IO is the bottleneck for the autoloader), except the fact that it would seem officially "endorsed". The frameworks would still have to ship their own versions because they have to support older PHP versions, where this isn't available. I think that the best solution would be having a generic autoloader infrastructure in the core, and having separate autoloading strategies( http://en.wikipedia.org/wiki/Strategy_pattern) offered, and one of them could be PSR-0(we could also add the PEAR/PEAR2 autoloader, etc.). That way people wouldn't think that the PSR-0 is the officially supported/endorsed/best autoloader out there. What do you think? -- Ferenc Kovács @Tyr43l - http://tyrael.hu
