2011/10/26 Matthew Weier O'Phinney weierophinney@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.
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.
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.?
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.)
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.)
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.)
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.
So the question becomes: should such a behavioural change be introduced
through the backdoor, in a PHP 5.x relase, by an autoloader?
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.
2011/10/26 Matthew Weier O'Phinney weierophinney@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.
Well, my personal opinion here is that you should discuss that in an
open list somewhere and put the RFC together, with examples, docs and
updated patch. The internals list is not really well suited to discuss
that, while I won't mind to have such discussions here, it may make
more sense to have a dedicated list. As it won't be the last
discussion you will have :)
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
2011/10/26 Matthew Weier O'Phinney weierophinney@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.Well, my personal opinion here is that you should discuss that in an
open list somewhere and put the RFC together, with examples, docs and
updated patch. The internals list is not really well suited to
discuss that, while I won't mind to have such discussions here, it may
make more sense to have a dedicated list. As it won't be the last
discussion you will have :)
The list exists already (http://groups.google.com/group/php-standards),
and implementation, RFC, examples, docs, etc. were already debated over
2 years ago, followed by implementations in several dozen projects.
What is happening at this point is completion of a C-level SPL class
providing a reference implementation that can be re-used directly from
the language itself. Even the original code for this was done around 2
years ago; the difference at this point is there is sufficient momentum
behind the standard to warrant a push to include it in the language.
This minimizes dependencies for projects following the standard, and
reduces duplication of effort.
The standard is detailed here:
https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md
I think the only relevant questions at this point are:
- Does the implementation follow the specification?
- Are there any technical objections that do not counter the
specification and which would bar inclusion in the language?
--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
Hi Mario,
2011/10/26 Matthew Weier O'Phinney weierophinney@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 toassert()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, besidesspl_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?
--
[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: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
Hello Guilherme,
2011/10/27 guilhermeblanco@gmail.com guilhermeblanco@gmail.com:
PHP-Standard list is also opened.
... since a few days.
But I'll happily take the discussion there. As I feel it doesn't belong here.
Discussing PSR-0 or how it came to be is entirely off-topic (and would be
rude).
We are just discussing the C implementation now and the effects it
would have on PHP core.
Already answered before. Performance is important. A native C
implementation is much faster than a PHP code implementation.
Well, that's always a safe assumption. But a shiny benchmark would be
useful in this review.
Interesting hard fact would to be know if -for the overall framework speed-
it makes a significant difference with or without bytecode cache. Shaving
off a few milliseconds, always cool. But percentages, more fascinating.
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 toassert()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.
Not sure if you understood, or just glanced over it, again.
I see that your specification mentions uppercase and lowercase characters.
It falls flat on mentioning any of the implications of their presence however.
You see, the only purpose an autoloader has is to map identifiers from
the programming language onto filenames from the operating system.
And there just happen to be functional differences between the two. Namely
identifiers in PHP (like class names) are NOT case-sensitive. But filenames
on the filesystem ARE. And then, on some other systems they ARE NOT.
This is not even cursorily explained by your specification. The most basic
autoloader requirement of defining an explicit and dependable mapping
between the two identifier systems is not met. It only talks about class names
and namespaces, but declares the translation onto filenames only by omission.
Yes, it's obvious that it implies mixed-case filenames. But it seemingly ignores
that this is a bidirectional dependency. Once you have mixed/fixed-case files,
you CAN'T have case-insensitive class names anymore.
There's no need to start a discussion about this here, or file subsequent
explanations. There was ample opportunity to do so on the FIG mailing list
after dissident debate has been locked out. Now why the identifier handling
discrepancy never occured to anyone in two years is beyond me. But it's
also irrelevant.
SplClassLoader anyway does not provide a language-compliant autoloader.
It can fail system-dependent to load class files when the PSR-0 file naming
is followed.
The first instantiation of a class may behave differently from all subsequent:
new \Test\UserThing;
new \Test\Userthing;
Might only work in this order, or the other, or maybe on Win-systems both cases.
(Again, thanks for not debating coding standards, but PHP language
behaviour here.)
Much unlike spl_autoload() which defines the only rational mapping. (And
you know, the custom autoloaders of some more contemporary frameworks,
where this very technical side effect was at least discussed.)
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
That's a valid reason for inclusion. "Everything is better if you wrap it in
objects" is baloney, mind you. But a procedural autoloader can represent
more of an obstacle to extension.
But do you have an example handy for SplClassLoader and how/why you'd
inherit from it? Have any of the 18+ frameworks tested their autoloading
with it? (Still concerned about customizing.)
being followed by 18+ widely adopted PHP projects. Which one would you
choose? An individual user suggestion or a group suggestion?
Wellllllllll. I would base the decision entirely on technical merits. Though
wouldn't rule out popularity or a faux standard completely either.
Cheers,
mario
Hello,
Already answered before. Performance is important. A native C
implementation is much faster than a PHP code implementation.
Well, that's always a safe assumption. But a shiny benchmark would be
useful in this review.
Interesting hard fact would to be know if -for the overall framework speed-
it makes a significant difference with or without bytecode cache. Shaving
off a few milliseconds, always cool. But percentages, more fascinating.
This is mostly relevant for performance in non-bytecode caches. Just as
most autoloading that leverages include paths. Same problem exists with the
main spl_autoload functionality if you do not define your own autoloader.
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 toassert()
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.
Not sure if you understood, or just glanced over it, again.
I see that your specification mentions uppercase and lowercase
characters.
It falls flat on mentioning any of the implications of their presence
however.You see, the only purpose an autoloader has is to map identifiers from
the programming language onto filenames from the operating system.
And there just happen to be functional differences between the two. Namely
identifiers in PHP (like class names) are NOT case-sensitive. But filenames
on the filesystem ARE. And then, on some other systems they ARE NOT.This is not even cursorily explained by your specification. The most basic
autoloader requirement of defining an explicit and dependable mapping
between the two identifier systems is not met. It only talks about class
names
and namespaces, but declares the translation onto filenames only by
omission.Yes, it's obvious that it implies mixed-case filenames. But it seemingly
ignores
that this is a bidirectional dependency. Once you have mixed/fixed-case
files,
you CAN'T have case-insensitive class names anymore.
The current spl_autoload default behavior works on windows great but say you
use the default on linux with mixed case file names? It's broken. As it is
today in the spl_autoload (default, not custom) we already have a
bidirectional dependency. Further what we are talking about here is that
there has been a major community adoption. All we are really talking about
here is default behavior since you could easily extend such an object to
change the behavior of the loading much like spl_autoload.
There's no need to start a discussion about this here, or file subsequent
explanations. There was ample opportunity to do so on the FIG mailing list
after dissident debate has been locked out. Now why the identifier handling
discrepancy never occured to anyone in two years is beyond me. But it's
also irrelevant.SplClassLoader anyway does not provide a language-compliant autoloader.
It can fail system-dependent to load class files when the PSR-0 file naming
is followed.
The first instantiation of a class may behave differently from all
subsequent:new \Test\UserThing; new \Test\Userthing;Might only work in this order, or the other, or maybe on Win-systems both
cases.
(Again, thanks for not debating coding standards, but PHP language
behaviour here.)Much unlike
spl_autoload()which defines the only rational mapping. (And
you know, the custom autoloaders of some more contemporary frameworks,
where this very technical side effect was at least discussed.)
This is an untruth. If you read the default source for spl_autoload; if you
did not call spl_autoload_register with any values it does search through
the include path; it also converts everything to lowercase. See the
following bug tickets:
https://bugs.php.net/bug.php?id=53065
https://bugs.php.net/bug.php?id=49852
There has been a previous thread on this subject as well (spl_autoload case
sensitivity):
http://marc.info/?l=php-internals&m=129336968406654&w=3
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 isThat's a valid reason for inclusion. "Everything is better if you wrap it
in
objects" is baloney, mind you. But a procedural autoloader can represent
more of an obstacle to extension.
But do you have an example handy for SplClassLoader and how/why you'd
inherit from it? Have any of the 18+ frameworks tested their autoloading
with it? (Still concerned about customizing.)
I don't have a handy one, however, if you look at some of the autoloaders in
the various frameworks they do have some additional methods that are added
on. However, here would be something to mimic spl_autoload's default
behavior:
MyClassLoader extends SplClassLoader {
public function loadClass($className) {
parent::loadClass(strtolower($className));
}
}
Regards,
Mike
To me, the interface found at https://wiki.php.net/rfc/splclassloader is
strange :
first, to be consistent with PSR-0, why allow changing the extension where
PSR-0 states that the only valid one is ".php"?
Why also have an interface to change the namespace separator?
Concerning userland specialization, I think the interface lacks a way to
intercept the path before "require". For example, if I want to preprocess a
file before including it, I can't with this code.
I find Symfony's interface much more powerful:
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/ClassLoader/UniversalClassLoader.php
About language semantics, I understand and support this reasoning:
- case insensitivity is good because having two different classes "Foo" and
"foo" makes absolutely no sense, - case sensitivity is good because mixing "Foo" and "foo" usage makes
absolutely no sense.
So, having a case sensitive loader is an extremely good thing because of 2.
And having a case insensitive PHP engine is also good because of 1. To go a
little further, I even think that PHP should trigger an E_STRICT when a
class is used with mixed case (first time "Foo", later "foo") but that's for
another topic :) To me, PHP current's behavior enforces 1., which is good,
but PHP can't encourage mixing "Foo" and "foo", so no semantic is broken
when the filesystem is case sensitive.
About PSR-0 and applying the same reasoning, I don't understand why the
underscore in the namespace part is not replaced by a directory separator:
because of it's class to path transformation, PSR-0 forbids having two
different classes named A\B_C and A\B\C (they map to the same file). That is
a good think, same reasoning for 1. above. But because of the "underscore in
namespace exception", PSR-0 encourages a situation where class A_B\C can
coexists with an other class A\B\C. Why forbid A\B_C and A\B\C, then allow
A_B\C and A\B\C? That is inconsistent with argument 1. above, which we have
used to justify PSR-0 equivalence for A\B_C and A\B\C... That is
inconsistent to me.
Hope it helps :)
Nicolas
There were several reasons for this.
First, to allow code following the current PEAR standards to work, we
obviously need to treat the "_" separator in class names as a directory
separator. Since the standard has its origins in the PEAR naming
conventions, this was a requirement.
Second, going back to the point made earlier in the thread about case
sensitivity, several projects indicated they planned to have lowercase
namespaces. As such, to allow for word separation, they wanted to use
the underscore character -- since namespaces must be in the character
set [a-zA-Z0-9_], this was the only available option. To allow
namespaces to use the underscore character, the standard then needed to
ignore underscores in substitutions on the namespace segment only.
So, to sum up:
- Allows BC with existing standards
- Allows greater naming flexibility in namespaces
Hope that answers your question.
--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc