Guilherme, > 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.
Actually, I'd argue that what you're saying here is the exact opposite of what a language should do. Does C enforce any standards? Does JavaScript? Does Java? Does Python? Does Perl? In some small way, yes they each do somewhat. But they don't define or evolve standards. There are technical limitations put in place for the standpoint of making the language usable or as a design decision. But they don't impose inconsistent "standards" upon users, especially when support for doing it in the "non-standard" way is working fine. I say inconsistent in the sense that "It works fine either way, but if you want to use this feature, you must *style* your code this way"... But this isn't about PHP standardizing on anything. As proponents of adding PSR-0 to the core have come out so hard to say, "It's optional". So if it's optional, it's not imposing a standard at all now, is it...? You can't have your cake and eat it too... > 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. The language does not need to focus on a paradigm. You can program in OOP in languages that do not support objects (There's tons of OOP C code out there). And you can write procedural code using classes (Just look at some of the projects you mentioned). There's nothing stopping you from picking any language and any paradigm and writing your code in it (You can write procedural Java). Even languages such as lisp and haskell are flexible enough to let you do what you want. The choice comes down to what do language designers and developers want to make *easy* and native. Support for native objects and interactions make writing OOP code easier. Support for first-class functions and immutable variable constructs makes writing functional code easier. But it doesn't restrict that language to that paradigm... It may provide an intended paradigm, but you can write any paradigm in any language (turing complete language that is). > Look at > spl_autoload_register. It focus in class loading (OO), but you're only > able to do it through a Procedural code. That's not a procedural construct. It's actually an OOP construct implemented using a function. Don't believe me? Go look up the Command pattern. It's basically almost exactly how spl_autoload_register works (more precisely, it's a hybrid of Command and Chain-Of-Responsibility). Using classes does not make code OOP. Writing OOP code does not require classes. It's that simple. > 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. 18 projects. With 260 members on the group. A large set, right? Except that there are by most estimates more than 6 MILLION PHP developers. Heck, the followers to this very list are many times more than that 260 number. My point is that like it or not, you'll always be a small subset of developers. Perhaps active. Perhaps vocal. Perhaps smarter. But with different interests than the vast majority of the PHP world. That's my point. Not that you're different, but your focus is different. You're not building your frameworks/projects for applications that get thousands of page views per second. If you did, the design choices (especially for this autoloader) would be quite different... You're not concerned with linking together existing code-bases that million-plus lines of code with new development. But you shouldn't be concerned about that. The core can quite easily accomplish both uses cases. But a "standard" such as this cannot. And it should not. > The language itself also endorses a standard recommendation: > http://www.php.net/manual/en/userlandnaming.rules.php That's not a standard for user-land code. That's a standard for CORE and PECL implementations. > 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. Have you looked at the implementations of PSR-0 as done by the 18 projects you specify (and others)? There is no standard implementation. There are limited sets of rules that are applied, but each implementation differs (sometimes significantly). For example, Symfony's loader is quite a bit different (Yet alone the fact that there are 5 of them) from the reference implementation. How is this handled by the proposed CORE class? Are all of the implementations that already exist out there supposed to just switch over? What about fundamental limitations such as 1Namespace -> 1Path mappings currently implemented? Are all of those features supposed to go away and adopt this one standard? The standard as written MIGHT be seen as a coding style standard. But it's NOT an implementation standard. There's no mention in the standard of how things are supposed to fail. There's no mention of how to handle edge-cases. There's no mention about how it should support 1Namespace->N Path mappings (although that's 100% supported by the standard as is now). So you have a style convention, but without an implementation standard. Does this RFC cover how the class loader can be extended in user-land to alter the behavior (remember, the implementation isn't specified, so we have have several implementations that differ yet follow the PSR-0 Standard). I don't really know what else I can say to try to get the point across... Anthony On Fri, Nov 4, 2011 at 1: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
