Comments are inline. On Thu, Nov 10, 2011 at 2:19 PM, Pierre Joye <pierre....@gmail.com> wrote: > On Thu, Nov 10, 2011 at 11:13 AM, Patrick ALLAERT > <patrickalla...@php.net> wrote: > >> You're mixing stuff here. >> "RFC on PSR-0 support into PHP status" != "PSR-0 status" > > I do not. But we are confusing our old vision and what users are looking for. > >> However, *how* PSR-0 might be introduced into PHP, for those who uses >> it, is for sure not ready yet and certainly not approved! >> >> I'm all for having a PSR-0 loader in the core of PHP, but if I voted >> "No", that is because I think the RFC is not ready yet. > > That's a single non intrusive function representing what has been > approved by many projects. Nobody is forced to use it nor does it > enforce anything. > >> Some are blocking because they kinda feel forced if this is introduced. >> Ignore those, PHP wouldn't have bundled ext/mysql for the same reasons >> about 15 years ago. >> >> I guess that some voted "No" because of lack of consensus. > > What amazes me is this exact argument. We never had, in the whole PHP > history, so many leading projects agreeing on something, together and > propose it to the core. I, for one, have been waiting for that to > happen for years (PEAR, etc.), and now that it is happening, what do > we do? 'No thanks', for whatever reasons. That's so wrong. >
Touching the subject that Pierre is rightly pointing out: -- Useless? Getting in the way? 1) This is an additional _and_ optional class to SPL. The SPL extension itself is even optional there is no enforcing here. The SPL itself is a collection of classes for very specific and different use cases, it's not getting in the way of anything. We are not bringing PSR into PHP, we are taking the concept we discovered that was highly successful, and taking that to PHP to continue to be even more successful. -- Small "pet projects" or small subset developers? 2) This isn't a "bunch" of developers, this is a bunch of the largest used PHP libraries in the world (ZF, Symfony, Doctrine, PPI, Drupal), count up how many people are using these libraries, building plugins, integrating parts of them together to make great tools and give PHP a great name that's in the _millions_. Only a few people in this scene have a voice, but they're voicing on behalf of the millions f developers and hundreds of companies that rely on there being consistency. Like Pierre said; it's very rare that you get so many leading projects able to agree on something that lets them all communicate together and share resources. Isn't that itself considerable enough to say "Ok here it is, lets see where this takes PHP libraries". This autoloading is actually strengthening the unity of the PHP community and its developer base. With a language as loose as PHP saying "You can do things your own way", for business you need consistency and compatibility and that's what is going to happen if we decide to make a SplClassLoader. 3) Go back ~5 years ago, PHP itself was big, but frameworks were just starting to get used. Now jump forward to today, what do you see? The majority of job requirements and software requirements for PHP applications is that they know ZF, Symfony, Doctrine. Why? Because it's a highly consistent package of tools that are being used to build great apps for the world. They agreed on their own class loader, so why not expand that success to any future library that's make and _optionally_ decides to become part of that eco-system. 4) How can we progress from what has evolved from point #3 above ? We must provide ways that help the major libraries work in the same direction, how can we do that? By enabling a class in our SPL library giving more consistency, what does this mean for new projects? By adhearing to SplClassLoader (a well accepted and generalised way of class mapping) it allows your new project to enter the prolific eco-system. So regardless of the author, or language, if it speaks PSR (or now, the default SplClassLoader mapping) it can be truly plug and play into thousands of applications loving this standard. 5) Inclusion into core? There are perfectly good reasons why it's being moved into core that's bundled with the major PHP distribution. If it was its own EXT, then it wouldn't be a convenient way to code, as it creates a dependency to install pecl libraries which isn't always within scope for users/companies/developers. If it is its own extension, then the push for it to be more accepted and widely used would have been a waste of time, only a small few are willing to go that extra mile, they are going to build their library to be the most compatible out of the box and thus we're requesting recognised justification for SPL inclusion. 6) Naming? The name 'psr' doesn't belong in PHP, it's a group of project leaders sitting down to see what we can do to make the PHP eco-system better. Much like an internals meeting but still in userland. The right place, and more extensible place in PHP that new features are going into, I would say, is SPL. It makes sense, it feels right and it has a good ~4 year proven track record for success. If the PHP language/team can recognise this and welcome these consistencies everybody is going to move forward in strength, rather than diverge. With all the above said, even if you personally don't use PSR, or any of the above libraries. This vote isn't about what you use, it's about the majority of the PHP developer base. Even if you personally don't use it, it doesn't mean you should vote _against_ it, considering you're not even being affected by the addition rather than modification to PHP. Thanks, I hope we can wipe the votes and have people take a second look at what we're proposing here. Regards, Paul Dragoonis. > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
