Hi Mario, On Wed, Oct 26, 2011 at 9:07 PM, <ma...@include-once.org> wrote: > 2011/10/26 Matthew Weier O'Phinney <weierophin...@php.net>: >> >> My main point, however, is that the standard was ratified quite some >> time ago already -- we just now have parties interested in creating a >> C-level implementation compatible with the standard to (a) make usage >> simpler, and (b) better optimize performance. We should not be debating >> the standard here, just the implementation. >> > > I'd like to object there. Now that we are discussing it on an open mailing > list again, both seem actually quite relevant.
PHP-Standard list is also opened. Anyone is able to contribute there too. We are requesting here is a standardization that was made between more than 18 well recognized PHP projects as a community request, not as an individual request. Anyone is able to open a new PR to official FIG (Framework Interoperability Group) repository[1] and start a new standard recommendation. If it'll ever be proposed to be accepted by core, it'll depends on how well it'll be accepted by PHP projects. > > > This is not the most important aspect here, but is there a *practical* > need to have a C implementation of this autoloader scheme? > > I mean no disrespect to the author; the code looks very nice and all. But it > hasn't exactly been widely tested yet. We have proven that it's possible to have some PHP standardization. Symfony 2, Zend Framework 2, Doctrine 2, Drupal, PPI, FLOW3, Typo3, and many other projects have successfully adopted a single and unique implementation of what we refer as PSR-0. This answers your question about wide adoption. Every implementor of PSR-0 have its own PHP implementation, either because of license restrictions, CLA, etc. But the implementation is almost the same (there're very few exceptions of docblocks and code indentation). We all love and propagate the re-usability principles, and as I previously exposed, PSR-0 is already a common code shared by many widely adopted projects. So why not keep in a unique place? Initially, it may sound like "ok, so open a GIT repository and everyone uses it", but the fact is that a native C implementation is much faster than a PHP implementation, and we're willing to contribute with the language that all of us work on daily. > > Moreover there are already many psr-0 userland implementations; practically > all with functional additions. Besides that SCL might not displace everyone > of them, it also seems kind of unnecessary. Because those existing autoloaders > in userland are fully operational.? Already answered before. Performance is important. A native C implementation is much faster than a PHP code implementation. > Having a default-proclaimed scheme in PHP core also feels a bit contrary > to allowing more specific userland autloaders. (Though still indespensable > for absorbing local customization and deployment discrepancies.) You missed the point. PSR-0 was untouched for over 2 years, without a single local customization. Of course the FIG board identified enhancements (such as multiple folders per namespace and multiple autoloading namespace addictions in a single class loader), but the kernel operation is untouched since its definition in 2009. The standardization of OO PHP code remains the same between all these project. It's proven to work, and it's proven that a standard can be reached in PHP, a language that is suffering so much by the lack of standardization. It may sound a bit offensive, but PHP has 10 ways to do the same thing, which opens so many possibilities that lead to so many bad code out there. > > I get that this is secondarily intended as optimization. But how much would > this matter in practice? It's mostly the bloaty frameworks (if I may say so) > that were to consider using it; where the benefit might be less measurable. > (And no, the smaller and newer frameworks don't all follow psr-0.) Any ms is important in a request. You may tell it's all framework's fault, but the support they provide, the amount of internal specific optimizations they made is so much that if you'd have to implement your own with same support, it'd take years and the performance would never be the same. We're here to talk about PHP standardization, not about code bloat in frameworks. Do not loose focus. > > >> >>>> The url for the RFC is: https://wiki.php.net/rfc/splclassloader > > But let's also discuss the *unmentioned* side effect of that proposal. > (I realize I'm opening a can of worms and a meta discussion here. > But I'd __politely request that people get over it already. And no, I > believe reducing case ambiguity was sensible language design.) It seems you have a personal feeling about this proposal. It's not a 1 man work that one, but rather a 20+ people. So forget about "can of worms". That proposal (PSR-0, which the RFC is entirely based on) was discussed for almost an year, inspected a huge range of projects and have been approved by 18 people. Of course we may have missed something, but the fact is that RFC is opened for anyone. You're perfectly able to make criticism about it, but being concise about that purpose of this RFC and how it can benefit the PHP projects is the main focus. Remember, PHP is not a standardized language. This is the secondary attempt to bring a standard to it. The first one was PDO. > > Now, PHP has case-insensitive identifiers. This includes function names, > class names, and not least namespaces. > > The proposed SplClassLoader would break that. Like PSR-0 it cannot satisfy > class name requests case-insensitively. The implementation approach is > indeterminate, depending on filesystem. > > Now the desire to enforce coding styles per autoloader will certainly come > up as post-factum rationalization here. But I'd also like to assert() that > this > creeping-in is even less acceptable from a language design point of view. > > For PHP6 there were discussions to drop BC and make identifiers case- > sensitive, just like in most other C-style languages. This has been shot > down. PSR-0 focus on a solid approach of class definition. But at the same time it does not touch naming conventions, except for file system class locations. If you read the mandatory section of PSR-0 [2], you'll see it's pretty explicit there this: - Alphabetic characters in vendor names, namespaces, and class names may be of any combination of lower case and upper case. So anything you said about case-sensitiveness is not broken by PSR-0. > So the question becomes: should such a behavioural change be introduced > through the backdoor, in a PHP 5.x relase, by an autoloader? As I previously exposed, it does not touch the naming conventions you adopt; your argument is broken. > Or is that issue too minor to care? After all it would be just a second > implementation, besides spl_autoload(). And again, retirement of custom > autoloaders is unlikely either way. The inclusion of SplClassLoader is just a secondary OO way to define spl_autoload. If you want to be critic, spl_autoload is a function, from the procedural paradigm. PHP does not have the OO implementation for the same, so the OO paradigm support is flawed currently in PHP. If you look at this perspective, an OO implementation is necessary (this is why I see no objections from PHP core and no objections for the standardization), but it should follow what is was defined as standard by the PHP community as a whole. The fact is that until now we have very sparse implementations of autoload that have own implementors' mindset an another one that is being followed by 18+ widely adopted PHP projects. Which one would you choose? An individual user suggestion or a group suggestion? > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > [1] https://github.com/php-fig/fig-standards [2] https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md -- 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
