SplClassLoader View as Markdown

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, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:

Hi Tyra3l,

Comments are inline.

On Thu, Nov 3, 2011 at 7:30 PM, Anthony Ferrara ircmaxell@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: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil

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, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:

Hi Tyra3l,

Comments are inline.

On Thu, Nov 3, 2011 at 7:30 PM, Anthony Ferrara ircmaxell@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: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil

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