my comments are also inline
> > did you read the blogpost? most of your replies were cowered there. > > > > Yes. you mean you or André? > > "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. > I just explained what I though Anthony was referring to. As it was pointed out already spl_autoload does lowercase the classname, so the current default autoload implementation doesn't suffer from this problem. Of course you can say that it is a PHP problem that the classnames are case insensitive, but I don't think that you are proposing to change that to solve the mentioned inconsistency. > > > 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". > I don't think that it was treated that way, could we keep the focus of the discussion on the technical level? > 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. There are languages where that is true, but imo PHP was always less strict about that. I'm not saying that it is good or bad, I'm just saying that I don't agree that "Everyone would expect". Of course it depends on how do you define Everyone. > 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. > PHP is a multi-paradigm language, and I'm not sure that we have to or will change that in the future. The fact that you have to use spl_autoload_register is (imo) because it is consistent with the set_error_handler, set_exception_handler(OO), register_shutdown_function, etc. > 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. > Could we please be allowed to have our opinion and express them in a reasonable discussion? Imo nobody is proposing that you can't have your rules to follow, but it was questioned whether it is a good idea to suggest/favor/force those rules on the whole community. Technically there is nothing major gain having this in the core (and there are some cons: the PHP version lifecycle is much slower than the average framework, so if we add, there will be slower/harder to introduce changes). This only makes sense from the "popularity" POV, as more people would use PSR-0, which has its merits, but most of it comes from the fact of having a common, general-purpose autoloader implementation, not from PSR-0 especially. > > > > > "(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 missed to address this. > > > > "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. > They are only a subset, as the group was somehow closed from the community feedback, to get things done, so while it represented the well-known projects, but that's still just a subset of the community. http://groups.google.com/group/php-standards/browse_thread/thread/05fda5b422e301cc# Btw. I wasn't aware that some bad blood was spilled between the PHP group and the PSG. That would explain some of the mails in this thread, but I would suggest putting the past behind us. > > > - 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 > > I wouldn't call that a convention, but a technical limitation/legacy "feature" of the past. The userland naming rules are for the php-src developers, not for the "userland" php devs. We don't take sides which is "The One True Brace Style" or that one should use CamelCase or not. > > - 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. > > Imo we don't know neither the supported php version of ZF3, nor the adoption rate of PHP 5.4, so I would go into that guessing game. But judging from the ZF roadmap (new version in every 18 months if I remember correctly), I'm sure that there won't be a new major or minor PHP version for every ZF version, so PHP will lag behind. > > > > 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. > > And I missed(albeit not really surprised) that PEAR2 Autoloader is compatible with PSR-0. So with that we can take the PEAR standard out of the picture. > 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. > Based on that, I think that if we add it to the core, it should be the least strict(most general) implementation, so it would work for most people out-of-the box, others could use it as a base class for their specific needs. > > 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. > I still think that to achieve that it is not mandatory to be in the core, but I'm not strongly against it. I just can see the points brought up by Anthony, and I somehow feel that pushing things by force is not the best thing to do. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
