Hi Tyra3l, Comments are inline.
On Fri, Nov 4, 2011 at 8:35 AM, Ferenc Kovacs <tyr...@gmail.com> wrote: > 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. > Yes. > "If you use lowerCamelCase on the class names or your namespace, it will > (/should) be exactly like on disk as well." > So as previously said, it just enforces that same standardization that happens in PHP code also happens in FileSystem. What you're pointing is not a PSR-0 a problem, it's a PHP problem. THe PSR-0 just highlights this issue and you're blindly telling it's SplClassLoader problem. > 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. Again, PHP is a language that lacks so much of standardization that every minimum effort to define one is treated as "against PHP's nature". The language is problematic, FIG/PSG are just trying to have zillions different implementations. Everyone would expect that language to set the standards, avoiding millions of weird pieces of code out there. As I said earlier, once PHP decides which paradigm it would focus, we would finally be able to standardize it. Right now we see fronts of OO, Procedural and Functional; and it's a total mess. Look at spl_autoload_register. It focus in class loading (OO), but you're only able to do it through a Procedural code. So please, stop pointing that community request A is against PHP nature. We live by PHP and all we want is to have a minimum set of rules to follow, rules that are language's task to provide, not ours. > > "(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). It wasn't created by a small subset. Over 18 projects worked on it. I doubt you'd consider Drupal, Wordpress, Zend Framework, Symfony, Typo3, Solr, PEAR and many others a small subset. Drupal and Wordpress by themselves are big enough to have voice over here. And we also have many others that are here not as a single person effort, but as a community request. This is the fact you are not paying attention. PHP community requested that, not only a few people. > - php core doesn't force/favor any coding convention/standard, why should > it do it for PSR-0? PHP enforces many conventions and I can refresh your mind. Every single keyword by itself is a convention. Also, variables names are case sensitive. Constants are case sensitive. The language itself also endorses a standard recommendation: http://www.php.net/manual/en/userlandnaming.rules.php > > "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. Great! We're on same page here. > - 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. As always, the same applied for namespace support. Have you looked that ZF1 is PHP 5.2+, while ZF2 is PHP 5.3+? What would you expect from ZF3? PHP 5.4+... Same applied to Symfony, Doctrine and many others. But if the language is unable to provide this support for library contributors, it's quite hard to NOT have this class in each library to circumvent the lack of support by PHP. > > 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? PSR-0 is already compatible with PEAR1. Actually, it is compatible with underscore to DIRECTORY_SEPARATOR used by many libraries in PHP 5.2 and also namespace to dir separator in PHP 5.3. This is not changing, and still following what PEAR standardized many years ago, but it seems the blog post author haven't looked at implementation for too long. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu > I may tend to agree with others that implementation is broken since its original implementation. After 2 years, all libraries that followed PSR-0 found out that we require multiple paths per namespace and also a possibility to silently fail if class loader cannot load a given class. But the fact is PSR-0 rules are kept, nothing changed in the last 2 years. Only the suggested implementation have changed, but again, that was just a recommendation, not an enforcement. FIG/PSG is intended to define interfaces that every interest can implement. We won't focus in PHP core functionality, but PSR-0 is the minimum lowest reasonable standardization to any OO library to implement, and it made sense for everyone to be in core. I doubt any other PSR would request changes in PHP officially. Cheers, -- 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
