Guilherme, What's the status regarding the finalised PSR-0 implementation so we can hand it over to DavidC to finish the C implementation and apply this to 5.4 branch.
Cheers, - Paul On Fri, Nov 4, 2011 at 5:27 PM, guilhermebla...@gmail.com <guilhermebla...@gmail.com> wrote: > 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
