Quick question: is there any planned inclusion in PHP for an SplClassLoader?
Cheers - rod.
Quick question: is there any planned inclusion in PHP for an SplClassLoader?
What would that class do that the spl_autoload*() functions don't?
-Hannes
I suppose what he means is a classloader implementation.
Something along the lines of:
function($class) {
return str_replace('\', DIRECTORY_SEPARATOR, $class) . '.php';
}
2011/6/27 Hannes Magnusson hannes.magnusson@gmail.com
Quick question: is there any planned inclusion in PHP for an
SplClassLoader?What would that class do that the spl_autoload*() functions don't?
-Hannes
Yes sorry this is what I mean, a PSR0 compliant autoloader class built
in as standard.
$loader = new SplClassLoader();
$loader->register( '/path/to/my/library' );
etc...
I suppose what he means is a classloader implementation.
Something along the lines of:
function($class) {
return str_replace('\', DIRECTORY_SEPARATOR, $class) . '.php';
}2011/6/27 Hannes Magnusson hannes.magnusson@gmail.com
Quick question: is there any planned inclusion in PHP for an
SplClassLoader?What would that class do that the spl_autoload*() functions don't?
-Hannes
Hannes,
There's a RFC covering this. There's a patch also.
https://wiki.php.net/rfc/splclassloader
[]s,
Yes sorry this is what I mean, a PSR0 compliant autoloader class built
in as standard.$loader = new SplClassLoader();
$loader->register( '/path/to/my/library' );
etc...I suppose what he means is a classloader implementation.
Something along the lines of:
function($class) {
return str_replace('\', DIRECTORY_SEPARATOR, $class) . '.php';
}2011/6/27 Hannes Magnusson hannes.magnusson@gmail.com
Quick question: is there any planned inclusion in PHP for an
SplClassLoader?What would that class do that the spl_autoload*() functions don't?
-Hannes
--
--
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
There's a RFC covering this. There's a patch also.
This one seems to have fallen through the cracks?
I know this would benefit many of the frameworks that are out there and give
a speed bump to people utilizing them. Is this a possibility for 5.4?
- The other implementation I could see is to modify spl_autoload to be able
to pass it a parameter for the auto loading type - right now it will attempt
to autoload everything lowercase (been brought up a few times).
Regards,
Mike
Hi!
There's a RFC covering this. There's a patch also.
This one seems to have fallen through the cracks?
Well, nobody proposed it in time (especially not the RFC author :)
- The other implementation I could see is to modify spl_autoload to be able
to pass it a parameter for the auto loading type - right now it will attempt
to autoload everything lowercase (been brought up a few times).
I think the class looks better. I think RFC needs to be expanded with
description of what the class actually does and how, and then if there
are no objections I think we could take it into 5.4.0, since the
implementation already exists.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi internals,
It's been a while since Stas accepted that, but it seems the class
haven't been merged since then.
What's the status of this? Can I expect SplClassLoader in 5.4.0?
It seems it was approved, but wasn't merged and thread was lost in space. =(
There's an RFC for it: https://wiki.php.net/rfc/splclassloader
There's a patch for it: https://github.com/metagoto/splclassloader
I'm not 100% sure the patch still works since it's been over 1 year
since it was proposed... =\
Cheers,
Hi!
There's a RFC covering this. There's a patch also.
This one seems to have fallen through the cracks?
Well, nobody proposed it in time (especially not the RFC author :)
- The other implementation I could see is to modify spl_autoload to be
able
to pass it a parameter for the auto loading type - right now it will
attempt
to autoload everything lowercase (been brought up a few times).I think the class looks better. I think RFC needs to be expanded with
description of what the class actually does and how, and then if there are
no objections I think we could take it into 5.4.0, since the implementation
already exists.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
On Mon, Oct 24, 2011 at 3:47 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:
Hi internals,
It's been a while since Stas accepted that, but it seems the class
haven't been merged since then.
What's the status of this? Can I expect SplClassLoader in 5.4.0?It seems it was approved, but wasn't merged and thread was lost in space. =(
There's an RFC for it: https://wiki.php.net/rfc/splclassloader
There's a patch for it: https://github.com/metagoto/splclassloaderI'm not 100% sure the patch still works since it's been over 1 year
since it was proposed... =\
I was also looking for this yesterday while implementing namespaces
into my project to be PSR-0 complaint. I did see metagoto's
implementation however would prefer to see something in /ext/*
Lets push it ! all major php libs would significantly benefit from
this addition from user-land into core.
- Paul Dragoonis.
Cheers,
Hi!
There's a RFC covering this. There's a patch also.
This one seems to have fallen through the cracks?
Well, nobody proposed it in time (especially not the RFC author :)
- The other implementation I could see is to modify spl_autoload to be
able
to pass it a parameter for the auto loading type - right now it will
attempt
to autoload everything lowercase (been brought up a few times).I think the class looks better. I think RFC needs to be expanded with
description of what the class actually does and how, and then if there are
no objections I think we could take it into 5.4.0, since the implementation
already exists.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
On Mon, Oct 24, 2011 at 3:47 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:Hi internals,
It's been a while since Stas accepted that, but it seems the class
haven't been merged since then.
What's the status of this? Can I expect SplClassLoader in 5.4.0?It seems it was approved, but wasn't merged and thread was lost in space. =(
There's an RFC for it: https://wiki.php.net/rfc/splclassloader
There's a patch for it: https://github.com/metagoto/splclassloader
If we can identify where we want it in the structure of the PHP
project, I'll be happy to merge the implementation and modify the
config files to have --enable-spl-autoloader or such.
Does anyone have a preference for this?
/ext/spl/
/ext/spl-loader/
/ext/spl-autoloader/
--
David Coallier
On Mon, Oct 24, 2011 at 3:47 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:Hi internals,
It's been a while since Stas accepted that, but it seems the class
haven't been merged since then.
What's the status of this? Can I expect SplClassLoader in 5.4.0?It seems it was approved, but wasn't merged and thread was lost in space. =(
There's an RFC for it: https://wiki.php.net/rfc/splclassloader
There's a patch for it: https://github.com/metagoto/splclassloaderIf we can identify where we want it in the structure of the PHP
project, I'll be happy to merge the implementation and modify the
config files to have --enable-spl-autoloader or such.Does anyone have a preference for this?
/ext/spl/
/ext/spl-loader/
/ext/spl-autoloader/
Hey David,
Since it has the prefix 'Spl' then I think it makes sense to add it as
a class to the existing /ext/spl/ extension, having it as its own
extension would be overkill me thinks.
- Paul Dragoonis.
--
David Coallier
On Mon, Oct 24, 2011 at 3:47 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:Hi internals,
It's been a while since Stas accepted that, but it seems the class
haven't been merged since then.
What's the status of this? Can I expect SplClassLoader in 5.4.0?It seems it was approved, but wasn't merged and thread was lost in space. =(
There's an RFC for it: https://wiki.php.net/rfc/splclassloader
There's a patch for it: https://github.com/metagoto/splclassloaderIf we can identify where we want it in the structure of the PHP
project, I'll be happy to merge the implementation and modify the
config files to have --enable-spl-autoloader or such.
Forgive me for not reading the code (yet) but what need is there for
an --enable-spl-autoloader flag?
What are peoples' thoughts on the name of the class? The word "auto"
fits best with all that has come before, yet the proposal here uses
"class": what about SplAutoloader? With the introduction of this new
class, whatever the name, what happens to __autoload() and
spl_autoload_register(), if anything? How many ways do we want/need to
load a class?
Does anyone have a preference for this?
/ext/spl/
/ext/spl-loader/
/ext/spl-autoloader/
IMO, new SPL functionality should live in ext/spl, we don't want to
spread the "standard library" too far and wide.
--
David Coallier
On Mon, Oct 24, 2011 at 10:20 AM, Peter Cowburn petercowburn@gmail.comwrote:
On Mon, Oct 24, 2011 at 3:47 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:Hi internals,
It's been a while since Stas accepted that, but it seems the class
haven't been merged since then.
What's the status of this? Can I expect SplClassLoader in 5.4.0?It seems it was approved, but wasn't merged and thread was lost in
space. =(There's an RFC for it: https://wiki.php.net/rfc/splclassloader
There's a patch for it: https://github.com/metagoto/splclassloaderIf we can identify where we want it in the structure of the PHP
project, I'll be happy to merge the implementation and modify the
config files to have --enable-spl-autoloader or such.Forgive me for not reading the code (yet) but what need is there for
an --enable-spl-autoloader flag?
I agree; I do not believe that there is a need for an enable flag in this
case. It should just be there or not at all.
What are peoples' thoughts on the name of the class? The word "auto"
fits best with all that has come before, yet the proposal here uses
"class": what about SplAutoloader? With the introduction of this new
class, whatever the name, what happens to __autoload() and
spl_autoload_register(), if anything? How many ways do we want/need to
load a class?
I believe by calling a class SplAutoloader when there is already an
implementation of spl_autoload that does something very different it would
be advised to not name it of the same sort... this is what people would
start to think about. The name SplClassLoader is much more specific. If we
needed to keep the word "Auto" it would seem better named
SplClassAutoLoader.
spl_autoload is completely separate from __autoload today. Also __autoload
does differ from the spl_autoload facility in several ways and is not
recommended even from the manual standpoint: www.php.net/autoload.
Secondarily; a class loader cannot autoload functions - it is made to only
implement PSR-0 and nothing more. While you may use spl_autoload to load
classes the implementation can also load in functions. This class is really
just enforcing a specific standardization.
What are peoples' thoughts on the name of the class? The word "auto"
fits best with all that has come before, yet the proposal here uses
"class": what about SplAutoloader? With the introduction of this new
class, whatever the name, what happens to __autoload() and
spl_autoload_register(), if anything? How many ways do we want/need to
load a class?I believe by calling a class SplAutoloader when there is already an
implementation of spl_autoload that does something very different it would
be advised to not name it of the same sort... this is what people would
start to think about. The name SplClassLoader is much more specific. If we
needed to keep the word "Auto" it would seem better named
SplClassAutoLoader.spl_autoload is completely separate from __autoload today. Also __autoload
does differ from the spl_autoload facility in several ways and is not
recommended even from the manual standpoint: www.php.net/autoload.
Secondarily; a class loader cannot autoload functions - it is made to only
implement PSR-0 and nothing more. While you may use spl_autoload to load
classes the implementation can also load in functions. This class is really
just enforcing a specific standardization.
I've started toying around with adjusting the patch. A bit of rewrite
is required but I'm attempting to modify the patch to be included
directly in SPL with the name SplClassLoader so that one can do:
$cl = new \SplClassLoader(..., ...);
Once the patch is adjusted to fit with SPL, we can revisit the name
however it is going to be used.
--
David Coallier
I've started toying around with adjusting the patch. A bit of rewrite
is required but I'm attempting to modify the patch to be included
directly in SPL with the name SplClassLoader so that one can do:$cl = new \SplClassLoader(..., ...);
Once the patch is adjusted to fit with SPL, we can revisit the name
however it is going to be used.
For the record: https://gist.github.com/1310352 (I know there are
Whitespaces issues, I'll get those resolved)
I'll be adding the tests tomorrow morning and then making sure the RFC
is adjusted.
--
David Coallier
hi,
Could you open a FR at bugs.php.net and attach the patch to it please?
Could be easier to track (and the # to the RFC too :)
I've started toying around with adjusting the patch. A bit of rewrite
is required but I'm attempting to modify the patch to be included
directly in SPL with the name SplClassLoader so that one can do:$cl = new \SplClassLoader(..., ...);
Once the patch is adjusted to fit with SPL, we can revisit the name
however it is going to be used.For the record: https://gist.github.com/1310352 (I know there are
Whitespaces issues, I'll get those resolved)I'll be adding the tests tomorrow morning and then making sure the RFC
is adjusted.--
David Coallier--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Could you open a FR at bugs.php.net and attach the patch to it please?
Could be easier to track (and the # to the RFC too :)
Yeah I'll do that once I have the tests adjusted and once I know the
patch actually works as expected.
--
David Coallier
Hi internals,
For all those interested, I have updated the RFC with better
explanation, included example implementation and also example usage.
If you have any other wishes, doubts, etc, feel free to ask on this
thread and I'll quickly answer here and also update the RFC
accordingly.
The url for the RFC is: https://wiki.php.net/rfc/splclassloader
Cheers,
Could you open a FR at bugs.php.net and attach the patch to it please?
Could be easier to track (and the # to the RFC too :)Yeah I'll do that once I have the tests adjusted and once I know the
patch actually works as expected.--
David Coallier--
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
I think the following two requirements should be covered by configuration
aswell:
- Have the autoloader be silent, i.e. doing a
file_exists()check. API idea
$loader = new SplClassLoader(..., SplClassLoader::SILENT); - Have a ASSERT_CLASS_EXISTS mode, i.e. after the require an
"if(!class_exists($class))" => throw new LogicException("SplClassLoader
expects class $class to be in $file, but after requiring the file this class
is still not loaded."); API here aswell "new SplCloassLoader(...,
SplClassLoader::ASSERT_CLASS_EXISTS)"
greetings,
Benjamin
On Tue, Oct 25, 2011 at 4:39 AM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:
Hi internals,
For all those interested, I have updated the RFC with better
explanation, included example implementation and also example usage.
If you have any other wishes, doubts, etc, feel free to ask on this
thread and I'll quickly answer here and also update the RFC
accordingly.The url for the RFC is: https://wiki.php.net/rfc/splclassloader
Cheers,
Could you open a FR at bugs.php.net and attach the patch to it please?
Could be easier to track (and the # to the RFC too :)Yeah I'll do that once I have the tests adjusted and once I know the
patch actually works as expected.--
David Coallier--
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
On Tue, Oct 25, 2011 at 12:49 PM, Benjamin Eberlei kontakt@beberlei.dewrote:
I think the following two requirements should be covered by configuration
aswell:
- Have the autoloader be silent, i.e. doing a
file_exists()check. API
idea
$loader = new SplClassLoader(..., SplClassLoader::SILENT);- Have a ASSERT_CLASS_EXISTS mode, i.e. after the require an
"if(!class_exists($class))" => throw new LogicException("SplClassLoader
expects class $class to be in $file, but after requiring the file this
class
is still not loaded."); API here aswell "new SplCloassLoader(...,
SplClassLoader::ASSERT_CLASS_EXISTS)"
What if 5.4 enhanced class_exists() to send a second true argument (an
optional argument, where default should be false) to autoloaders, then users
wouldn't have to deal with silent vs noisy modes at all.
So signature of autoload functions becomes:
function load( string $className, bool $checkExistence = false );
In the case of splClassLoader, $checkExistence = false would for instance
mean you would get a *E_COMPILE_ERROR *(requrie) if the class does not exist
but does match the configured root name spaced to be handled, if the
argument is true, then a bool is returned.
greetings,
BenjaminOn Tue, Oct 25, 2011 at 4:39 AM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:Hi internals,
For all those interested, I have updated the RFC with better
explanation, included example implementation and also example usage.
If you have any other wishes, doubts, etc, feel free to ask on this
thread and I'll quickly answer here and also update the RFC
accordingly.The url for the RFC is: https://wiki.php.net/rfc/splclassloader
Cheers,
Could you open a FR at bugs.php.net and attach the patch to it
please?
Could be easier to track (and the # to the RFC too :)Yeah I'll do that once I have the tests adjusted and once I know the
patch actually works as expected.--
David Coallier--
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
On Tue, Oct 25, 2011 at 4:39 AM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:
Hi internals,
For all those interested, I have updated the RFC with better
explanation, included example implementation and also example usage.
If you have any other wishes, doubts, etc, feel free to ask on this
thread and I'll quickly answer here and also update the RFC
accordingly.
As sent to the PHP-SWG list, a small change / addition to PSR-0 would
simplify the matching considerably.
If this rule:
- Each “” character in the CLASS NAME is converted to a
DIRECTORY_SEPARATOR. The “” character has no special meaning in the
namespace.
is changed to
- Each “_” character in the CLASS NAME and NAMESPACE is converted to a
DIRECTORY_SEPARATOR.
Or a strict mode is added to enable that, then you'll reduce 6 string
function to 2, and still have backward support for PEAR class naming(w/o
namespace).
The url for the RFC is: https://wiki.php.net/rfc/splclassloader
Cheers,
Could you open a FR at bugs.php.net and attach the patch to it please?
Could be easier to track (and the # to the RFC too :)Yeah I'll do that once I have the tests adjusted and once I know the
patch actually works as expected.--
David Coallier--
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
--bcaec5216025460b0e04b031fc2a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printableOn Tue, Oct 25, 2011 at 4:39 AM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:For all those interested, I have updated the RFC with better
explanation, included example implementation and also example usage.
If you have any other wishes, doubts, etc, feel free to ask on this
thread and I'll quickly answer here and also update the RFC
accordingly.As sent to the PHP-SWG list, a small change / addition to PSR-0 would
simplify the matching considerably.If this rule:
- Each "" character in the CLASS NAME is converted to a
DIRECTORY_SEPARATOR. The "" character has no special meaning in
the namespace.is changed to
- Each "_" character in the CLASS NAME and NAMESPACE is converted to a
DIRECTORY_SEPARATOR.Or a strict mode is added to enable that, then you'll reduce 6 string
function to 2, and still have backward support for PEAR class naming(w/o
namespace).
Actually, it still works, with no modifications. PEAR 1 classes exist in
the global namespace, and as such, the "_" in the classname rule
triggers. As such, a PSR-0 compatible autoloader will load PEAR 1
classes as well as those written using namespaces in PHP 5.3. The
difference right now is that PSR-0 now differentiates namespace
conventions from class name conventions.
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.
The url for the RFC is: https://wiki.php.net/rfc/splclassloader
Cheers,
Could you open a FR at bugs.php.net and attach the patch to it please?
Could be easier to track (and the # to the RFC too :)Yeah I'll do that once I have the tests adjusted and once I know the
patch actually works as expected.--
David Coallier--
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
S=C3=A3o Paulo - SP/Brazil--
--bcaec5216025460b0e04b031fc2a--
--
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
2011/10/26 André Rømcke ar@ez.no:
On Tue, Oct 25, 2011 at 4:39 AM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:Hi internals,
For all those interested, I have updated the RFC with better
explanation, included example implementation and also example usage.
If you have any other wishes, doubts, etc, feel free to ask on this
thread and I'll quickly answer here and also update the RFC
accordingly.As sent to the PHP-SWG list, a small change / addition to PSR-0 would
simplify the matching considerably.If this rule:
- Each “” character in the CLASS NAME is converted to a
DIRECTORY_SEPARATOR. The “” character has no special meaning in the
namespace.is changed to
- Each “” character in the CLASS NAME and NAMESPACE is converted to a
DIRECTORY_SEPARATOR.
There is a internal autoloader in
Yaf(http://svn.php.net/viewvc/pecl/yaf/trunk/yaf_loader.c?view=markup),
in it theT_NS_SEPARATORwill convert to be "", then convert to be
DIRECTORY_SEPARATOR.
thanks
Or a strict mode is added to enable that, then you'll reduce 6 string
function to 2, and still have backward support for PEAR class naming(w/o
namespace).The url for the RFC is: https://wiki.php.net/rfc/splclassloader
Cheers,
Could you open a FR at bugs.php.net and attach the patch to it please?
Could be easier to track (and the # to the RFC too :)Yeah I'll do that once I have the tests adjusted and once I know the
patch actually works as expected.--
David Coallier--
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil--
--
Laruence Xinchen Hui
http://www.laruence.com/
2011/10/26 André Rømcke ar@ez.no:
On Tue, Oct 25, 2011 at 4:39 AM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:Hi internals,
For all those interested, I have updated the RFC with better
explanation, included example implementation and also example usage.
If you have any other wishes, doubts, etc, feel free to ask on this
thread and I'll quickly answer here and also update the RFC
accordingly.As sent to the PHP-SWG list, a small change / addition to PSR-0 would
simplify the matching considerably.If this rule:
- Each “” character in the CLASS NAME is converted to a
DIRECTORY_SEPARATOR. The “” character has no special meaning in the
namespace.is changed to
- Each “” character in the CLASS NAME and NAMESPACE is converted to a
DIRECTORY_SEPARATOR.
There is a internal autoloader in
Yaf(http://svn.php.net/viewvc/pecl/yaf/trunk/yaf_loader.c?view=markup),
in it theT_NS_SEPARATORwill convert to be "", then convert to be
DIRECTORY_SEPARATOR.thanks
As mentioned by others this will have to go into a new PSR standard as
PSR-0 was accepted 2 years ago.
And assuming that a C implementation will greatly out-weight the reduced
amount of str functions in terms performance we should not block this
process to get it into 5.4 by taking up off-topic subjects like mentioning
things not part of PSR-0.
But!
The implementation proposal (rfc) should be adjusted to be
forward compatible, including support for several namespaces pr instance
(mention by several on PSR mailing list) imho.
Possible example (additional arguments can be added later when more
features are added, aka a PSR-1 mode):
new SplClassLoader( array( 'Doctrine\Common' => '/path/to/doctrine' ) );
Or something like this (if we want the options to be an array):
new SplClassLoader( array( 'ns' => array( 'Doctrine\Common' =>
'/path/to/doctrine' ) ) );
For documentation and argument validation, imo the former approach would be
better.
So what is the status here? thread has been silent for a while.
Or a strict mode is added to enable that, then you'll reduce 6 string
function to 2, and still have backward support for PEAR class naming(w/o
namespace).The url for the RFC is: https://wiki.php.net/rfc/splclassloader
Cheers,
Could you open a FR at bugs.php.net and attach the patch to it
please?
Could be easier to track (and the # to the RFC too :)Yeah I'll do that once I have the tests adjusted and once I know the
patch actually works as expected.--
David Coallier--
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil--
--
Laruence Xinchen Hui
http://www.laruence.com/
Can I make a point here.
Why the heck are we caring about the performance of the autoloader at
all here? The filesystem operations necessary (at least the stat()
call) will greatly dominate any string function. And considering that
even the biggest framework only has perhaps a few hundred classes,
you're talking about incredibly small performance gains here. Even if
you save a microsecond in string operations (try it, even in PHP the
string operations can be done in around 10 or 20 microseconds), after
all classes are loaded you're only talking about a 1 or 2 milliseconds
of gain in the application.
I'm not saying that we shouldn't try to save time where we can, but
given the controversial nature of this addition, I don't think that a
micro-optimization (which is what this really is) should be used as a
justification for why it should be included. It's not like we're
talking about implementing a computationally difficult task into C
(such as a cryptographic algorithm) where putting it into C would
create a huge performance gain. We're talking about implementing a
function which already is dominated by non-computational overhead into
C to save a few milliseconds. The number of instances that will
benefit from such an addition are incredibly small. Saving 2
milliseconds on an application (that likely takes hundreds of
milliseconds to render) would require a huge number of requests to
amortize into an actual measurable benefit. And those that do benefit
would have access to their server farm to add the pecl extension
anyway. So there's really no practical performance gain to the
community as a whole, hence confirming that this is a
micro-optimization.
Personally I feel that this does not belong in the core (especially
not yet as with the inconsistencies).
But that's besides the point. I just want to emphasize the point that
performance should not be a criteria for justifying it going into the
core...
Anthony
2011/10/26 André Rømcke ar@ez.no:
On Tue, Oct 25, 2011 at 4:39 AM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:Hi internals,
For all those interested, I have updated the RFC with better
explanation, included example implementation and also example usage.
If you have any other wishes, doubts, etc, feel free to ask on this
thread and I'll quickly answer here and also update the RFC
accordingly.As sent to the PHP-SWG list, a small change / addition to PSR-0 would
simplify the matching considerably.If this rule:
- Each “” character in the CLASS NAME is converted to a
DIRECTORY_SEPARATOR. The “” character has no special meaning in the
namespace.is changed to
- Each “” character in the CLASS NAME and NAMESPACE is converted to a
DIRECTORY_SEPARATOR.
There is a internal autoloader in
Yaf(http://svn.php.net/viewvc/pecl/yaf/trunk/yaf_loader.c?view=markup),
in it theT_NS_SEPARATORwill convert to be "", then convert to be
DIRECTORY_SEPARATOR.thanks
As mentioned by others this will have to go into a new PSR standard as
PSR-0 was accepted 2 years ago.And assuming that a C implementation will greatly out-weight the reduced
amount of str functions in terms performance we should not block this
process to get it into 5.4 by taking up off-topic subjects like mentioning
things not part of PSR-0.But!
The implementation proposal (rfc) should be adjusted to be
forward compatible, including support for several namespaces pr instance
(mention by several on PSR mailing list) imho.Possible example (additional arguments can be added later when more
features are added, aka a PSR-1 mode):new SplClassLoader( array( 'Doctrine\Common' => '/path/to/doctrine' ) );
Or something like this (if we want the options to be an array):
new SplClassLoader( array( 'ns' => array( 'Doctrine\Common' =>
'/path/to/doctrine' ) ) );For documentation and argument validation, imo the former approach would be
better.
So what is the status here? thread has been silent for a while.Or a strict mode is added to enable that, then you'll reduce 6 string
function to 2, and still have backward support for PEAR class naming(w/o
namespace).The url for the RFC is: https://wiki.php.net/rfc/splclassloader
Cheers,
Could you open a FR at bugs.php.net and attach the patch to it
please?
Could be easier to track (and the # to the RFC too :)Yeah I'll do that once I have the tests adjusted and once I know the
patch actually works as expected.--
David Coallier--
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil--
--
Laruence Xinchen Hui
http://www.laruence.com/
Can I make a point here.
Why the heck are we caring about the performance of the autoloader at
all here? The filesystem operations necessary (at least thestat()
call) will greatly dominate any string function. And considering that
even the biggest framework only has perhaps a few hundred classes,
you're talking about incredibly small performance gains here. Even if
you save a microsecond in string operations (try it, even in PHP the
string operations can be done in around 10 or 20 microseconds), after
all classes are loaded you're only talking about a 1 or 2 milliseconds
of gain in the application.I'm not saying that we shouldn't try to save time where we can, but
given the controversial nature of this addition, I don't think that a
micro-optimization (which is what this really is) should be used as a
justification for why it should be included. It's not like we're
talking about implementing a computationally difficult task into C
(such as a cryptographic algorithm) where putting it into C would
create a huge performance gain. We're talking about implementing a
function which already is dominated by non-computational overhead into
C to save a few milliseconds. The number of instances that will
benefit from such an addition are incredibly small. Saving 2
milliseconds on an application (that likely takes hundreds of
milliseconds to render) would require a huge number of requests to
amortize into an actual measurable benefit. And those that do benefit
would have access to their server farm to add the pecl extension
anyway. So there's really no practical performance gain to the
community as a whole, hence confirming that this is a
micro-optimization.Personally I feel that this does not belong in the core (especially
not yet as with the inconsistencies).But that's besides the point. I just want to emphasize the point that
performance should not be a criteria for justifying it going into the
core...
You mixing up one of my personal objectives* with the poster's objective**
(which I also share).
- making the class map based vs convention based performance discussion
moot, making sure more people will standardize around PSR-0
** making sure there is a autoloader in php that follows a convention that
people actually use, and further standardized how such a basic thing is
done in php projects in the wild.
2011/10/26 André Rømcke ar@ez.no:
On Tue, Oct 25, 2011 at 4:39 AM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:Hi internals,
For all those interested, I have updated the RFC with better
explanation, included example implementation and also example usage.
If you have any other wishes, doubts, etc, feel free to ask on this
thread and I'll quickly answer here and also update the RFC
accordingly.As sent to the PHP-SWG list, a small change / addition to PSR-0 would
simplify the matching considerably.If this rule:
- Each “” character in the CLASS NAME is converted to a
DIRECTORY_SEPARATOR. The “” character has no special meaning in the
namespace.is changed to
- Each “” character in the CLASS NAME and NAMESPACE is converted to a
DIRECTORY_SEPARATOR.
There is a internal autoloader in
Yaf(http://svn.php.net/viewvc/pecl/yaf/trunk/yaf_loader.c?view=markup),
in it theT_NS_SEPARATORwill convert to be "", then convert to be
DIRECTORY_SEPARATOR.thanks
As mentioned by others this will have to go into a new PSR standard as
PSR-0 was accepted 2 years ago.And assuming that a C implementation will greatly out-weight the reduced
amount of str functions in terms performance we should not block this
process to get it into 5.4 by taking up off-topic subjects like
mentioning
things not part of PSR-0.But!
The implementation proposal (rfc) should be adjusted to be
forward compatible, including support for several namespaces pr instance
(mention by several on PSR mailing list) imho.Possible example (additional arguments can be added later when more
features are added, aka a PSR-1 mode):new SplClassLoader( array( 'Doctrine\Common' => '/path/to/doctrine' ) );
Or something like this (if we want the options to be an array):
new SplClassLoader( array( 'ns' => array( 'Doctrine\Common' =>
'/path/to/doctrine' ) ) );For documentation and argument validation, imo the former approach would
be
better.
So what is the status here? thread has been silent for a while.Or a strict mode is added to enable that, then you'll reduce 6 string
function to 2, and still have backward support for PEAR class
naming(w/o
namespace).The url for the RFC is: https://wiki.php.net/rfc/splclassloader
Cheers,
On Mon, Oct 24, 2011 at 7:55 PM, David Coallier davidc@php.net
wrote:Could you open a FR at bugs.php.net and attach the patch to it
please?
Could be easier to track (and the # to the RFC too :)Yeah I'll do that once I have the tests adjusted and once I know
the
patch actually works as expected.--
David Coallier--
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil--
--
Laruence Xinchen Hui
http://www.laruence.com/
Can I make a point here.
Why the heck are we caring about the performance of the autoloader at
all here? The filesystem operations necessary (at least thestat()
call) will greatly dominate any string function. And considering that
even the biggest framework only has perhaps a few hundred classes,
you're talking about incredibly small performance gains here. Even if
you save a microsecond in string operations (try it, even in PHP the
string operations can be done in around 10 or 20 microseconds), after
all classes are loaded you're only talking about a 1 or 2 milliseconds
of gain in the application.I'm not saying that we shouldn't try to save time where we can, but
given the controversial nature of this addition, I don't think that a
micro-optimization (which is what this really is) should be used as a
justification for why it should be included. It's not like we're
talking about implementing a computationally difficult task into C
(such as a cryptographic algorithm) where putting it into C would
create a huge performance gain. We're talking about implementing a
function which already is dominated by non-computational overhead into
C to save a few milliseconds. The number of instances that will
benefit from such an addition are incredibly small. Saving 2
milliseconds on an application (that likely takes hundreds of
milliseconds to render) would require a huge number of requests to
amortize into an actual measurable benefit. And those that do benefit
would have access to their server farm to add the pecl extension
anyway. So there's really no practical performance gain to the
community as a whole, hence confirming that this is a
micro-optimization.Personally I feel that this does not belong in the core (especially
not yet as with the inconsistencies).But that's besides the point. I just want to emphasize the point that
performance should not be a criteria for justifying it going into the
core...Anthony
Basically, theres approx a dozen of the most recognised PHP libraries
that are advocating the use of a generalised class mapping standard.
This is great, and allows switching between projects very seamless as
there's no additional learning curve.
while(consistency) learning_curve--;
If library vendors are implementing their own custom autoloading
structure/mechanism it's very counter-productive to the PHP
eco-system. The point of PSR-0 is to create a standard to allow
compatibility between vendor libs such as ZF/Symfony/PPI.
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.
It's also giving existing lib vendors to easily switch to a well-built
autoloading mechanism bundled with PHP rather than relying on
third-party code to provide that. Additionally the small performance
boost but including SplClassLoader is not driven by the speed benefit
but by the community/library benefit.
This appears to be the general consensus of PSR-0 and my opinion on the matter.
Regards,
Paul Dragoonis.
2011/10/26 André Rømcke ar@ez.no:
On Tue, Oct 25, 2011 at 4:39 AM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:Hi internals,
For all those interested, I have updated the RFC with better
explanation, included example implementation and also example usage.
If you have any other wishes, doubts, etc, feel free to ask on this
thread and I'll quickly answer here and also update the RFC
accordingly.As sent to the PHP-SWG list, a small change / addition to PSR-0 would
simplify the matching considerably.If this rule:
- Each “” character in the CLASS NAME is converted to a
DIRECTORY_SEPARATOR. The “” character has no special meaning in the
namespace.is changed to
- Each “” character in the CLASS NAME and NAMESPACE is converted to a
DIRECTORY_SEPARATOR.
There is a internal autoloader in
Yaf(http://svn.php.net/viewvc/pecl/yaf/trunk/yaf_loader.c?view=markup),
in it theT_NS_SEPARATORwill convert to be "", then convert to be
DIRECTORY_SEPARATOR.thanks
As mentioned by others this will have to go into a new PSR standard as
PSR-0 was accepted 2 years ago.And assuming that a C implementation will greatly out-weight the reduced
amount of str functions in terms performance we should not block this
process to get it into 5.4 by taking up off-topic subjects like mentioning
things not part of PSR-0.But!
The implementation proposal (rfc) should be adjusted to be
forward compatible, including support for several namespaces pr instance
(mention by several on PSR mailing list) imho.Possible example (additional arguments can be added later when more
features are added, aka a PSR-1 mode):new SplClassLoader( array( 'Doctrine\Common' => '/path/to/doctrine' ) );
Or something like this (if we want the options to be an array):
new SplClassLoader( array( 'ns' => array( 'Doctrine\Common' =>
'/path/to/doctrine' ) ) );For documentation and argument validation, imo the former approach would be
better.
So what is the status here? thread has been silent for a while.Or a strict mode is added to enable that, then you'll reduce 6 string
function to 2, and still have backward support for PEAR class naming(w/o
namespace).The url for the RFC is: https://wiki.php.net/rfc/splclassloader
Cheers,
Could you open a FR at bugs.php.net and attach the patch to it
please?
Could be easier to track (and the # to the RFC too :)Yeah I'll do that once I have the tests adjusted and once I know the
patch actually works as expected.--
David Coallier--
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil--
--
Laruence Xinchen Hui
http://www.laruence.com/
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
Anthony
Can I make a point here.
Why the heck are we caring about the performance of the autoloader at
all here? The filesystem operations necessary (at least thestat()
call) will greatly dominate any string function. And considering that
even the biggest framework only has perhaps a few hundred classes,
you're talking about incredibly small performance gains here. Even if
you save a microsecond in string operations (try it, even in PHP the
string operations can be done in around 10 or 20 microseconds), after
all classes are loaded you're only talking about a 1 or 2 milliseconds
of gain in the application.I'm not saying that we shouldn't try to save time where we can, but
given the controversial nature of this addition, I don't think that a
micro-optimization (which is what this really is) should be used as a
justification for why it should be included. It's not like we're
talking about implementing a computationally difficult task into C
(such as a cryptographic algorithm) where putting it into C would
create a huge performance gain. We're talking about implementing a
function which already is dominated by non-computational overhead into
C to save a few milliseconds. The number of instances that will
benefit from such an addition are incredibly small. Saving 2
milliseconds on an application (that likely takes hundreds of
milliseconds to render) would require a huge number of requests to
amortize into an actual measurable benefit. And those that do benefit
would have access to their server farm to add the pecl extension
anyway. So there's really no practical performance gain to the
community as a whole, hence confirming that this is a
micro-optimization.Personally I feel that this does not belong in the core (especially
not yet as with the inconsistencies).But that's besides the point. I just want to emphasize the point that
performance should not be a criteria for justifying it going into the
core...Anthony
Basically, theres approx a dozen of the most recognised PHP libraries
that are advocating the use of a generalised class mapping standard.This is great, and allows switching between projects very seamless as
there's no additional learning curve.
while(consistency) learning_curve--;If library vendors are implementing their own custom autoloading
structure/mechanism it's very counter-productive to the PHP
eco-system. The point of PSR-0 is to create a standard to allow
compatibility between vendor libs such as ZF/Symfony/PPI.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.
It's also giving existing lib vendors to easily switch to a well-built
autoloading mechanism bundled with PHP rather than relying on
third-party code to provide that. Additionally the small performance
boost but including SplClassLoader is not driven by the speed benefit
but by the community/library benefit.This appears to be the general consensus of PSR-0 and my opinion on the matter.
Regards,
Paul Dragoonis.2011/10/26 André Rømcke ar@ez.no:
On Tue, Oct 25, 2011 at 4:39 AM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:Hi internals,
For all those interested, I have updated the RFC with better
explanation, included example implementation and also example usage.
If you have any other wishes, doubts, etc, feel free to ask on this
thread and I'll quickly answer here and also update the RFC
accordingly.As sent to the PHP-SWG list, a small change / addition to PSR-0 would
simplify the matching considerably.If this rule:
- Each “” character in the CLASS NAME is converted to a
DIRECTORY_SEPARATOR. The “” character has no special meaning in the
namespace.is changed to
- Each “” character in the CLASS NAME and NAMESPACE is converted to a
DIRECTORY_SEPARATOR.
There is a internal autoloader in
Yaf(http://svn.php.net/viewvc/pecl/yaf/trunk/yaf_loader.c?view=markup),
in it theT_NS_SEPARATORwill convert to be "", then convert to be
DIRECTORY_SEPARATOR.thanks
As mentioned by others this will have to go into a new PSR standard as
PSR-0 was accepted 2 years ago.And assuming that a C implementation will greatly out-weight the reduced
amount of str functions in terms performance we should not block this
process to get it into 5.4 by taking up off-topic subjects like mentioning
things not part of PSR-0.But!
The implementation proposal (rfc) should be adjusted to be
forward compatible, including support for several namespaces pr instance
(mention by several on PSR mailing list) imho.Possible example (additional arguments can be added later when more
features are added, aka a PSR-1 mode):new SplClassLoader( array( 'Doctrine\Common' => '/path/to/doctrine' ) );
Or something like this (if we want the options to be an array):
new SplClassLoader( array( 'ns' => array( 'Doctrine\Common' =>
'/path/to/doctrine' ) ) );For documentation and argument validation, imo the former approach would be
better.
So what is the status here? thread has been silent for a while.Or a strict mode is added to enable that, then you'll reduce 6 string
function to 2, and still have backward support for PEAR class naming(w/o
namespace).The url for the RFC is: https://wiki.php.net/rfc/splclassloader
Cheers,
Could you open a FR at bugs.php.net and attach the patch to it
please?
Could be easier to track (and the # to the RFC too :)Yeah I'll do that once I have the tests adjusted and once I know the
patch actually works as expected.--
David Coallier--
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil--
--
Laruence Xinchen Hui
http://www.laruence.com/
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? :)
Anthony
On Thu, Nov 3, 2011 at 12:07 PM, Paul Dragoonis dragoonis@gmail.com
wrote:On Thu, Nov 3, 2011 at 3:19 PM, Anthony Ferrara ircmaxell@gmail.com
wrote:Can I make a point here.
Why the heck are we caring about the performance of the autoloader at
all here? The filesystem operations necessary (at least thestat()
call) will greatly dominate any string function. And considering that
even the biggest framework only has perhaps a few hundred classes,
you're talking about incredibly small performance gains here. Even if
you save a microsecond in string operations (try it, even in PHP the
string operations can be done in around 10 or 20 microseconds), after
all classes are loaded you're only talking about a 1 or 2 milliseconds
of gain in the application.I'm not saying that we shouldn't try to save time where we can, but
given the controversial nature of this addition, I don't think that a
micro-optimization (which is what this really is) should be used as a
justification for why it should be included. It's not like we're
talking about implementing a computationally difficult task into C
(such as a cryptographic algorithm) where putting it into C would
create a huge performance gain. We're talking about implementing a
function which already is dominated by non-computational overhead into
C to save a few milliseconds. The number of instances that will
benefit from such an addition are incredibly small. Saving 2
milliseconds on an application (that likely takes hundreds of
milliseconds to render) would require a huge number of requests to
amortize into an actual measurable benefit. And those that do benefit
would have access to their server farm to add the pecl extension
anyway. So there's really no practical performance gain to the
community as a whole, hence confirming that this is a
micro-optimization.Personally I feel that this does not belong in the core (especially
not yet as with the inconsistencies).But that's besides the point. I just want to emphasize the point that
performance should not be a criteria for justifying it going into the
core...Anthony
Basically, theres approx a dozen of the most recognised PHP libraries
that are advocating the use of a generalised class mapping standard.This is great, and allows switching between projects very seamless as
there's no additional learning curve.
while(consistency) learning_curve--;If library vendors are implementing their own custom autoloading
structure/mechanism it's very counter-productive to the PHP
eco-system. The point of PSR-0 is to create a standard to allow
compatibility between vendor libs such as ZF/Symfony/PPI.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.
It's also giving existing lib vendors to easily switch to a well-built
autoloading mechanism bundled with PHP rather than relying on
third-party code to provide that. Additionally the small performance
boost but including SplClassLoader is not driven by the speed benefit
but by the community/library benefit.This appears to be the general consensus of PSR-0 and my opinion on the
matter.Regards,
Paul Dragoonis.2011/10/26 André Rømcke ar@ez.no:
On Tue, Oct 25, 2011 at 4:39 AM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:Hi internals,
For all those interested, I have updated the RFC with better
explanation, included example implementation and also example
usage.
If you have any other wishes, doubts, etc, feel free to ask on this
thread and I'll quickly answer here and also update the RFC
accordingly.As sent to the PHP-SWG list, a small change / addition to PSR-0
would
simplify the matching considerably.If this rule:
- Each “” character in the CLASS NAME is converted to a
DIRECTORY_SEPARATOR. The “” character has no special meaning in the
namespace.is changed to
- Each “” character in the CLASS NAME and NAMESPACE is converted
to a
DIRECTORY_SEPARATOR.
There is a internal autoloader in
Yaf(http://svn.php.net/viewvc/pecl/yaf/trunk/yaf_loader.c?view=markup
),
in it theT_NS_SEPARATORwill convert to be "", then convert to be
DIRECTORY_SEPARATOR.thanks
As mentioned by others this will have to go into a new PSR standard as
PSR-0 was accepted 2 years ago.And assuming that a C implementation will greatly out-weight the
reduced
amount of str functions in terms performance we should not block this
process to get it into 5.4 by taking up off-topic subjects like
mentioning
things not part of PSR-0.But!
The implementation proposal (rfc) should be adjusted to be
forward compatible, including support for several namespaces pr
instance
(mention by several on PSR mailing list) imho.Possible example (additional arguments can be added later when more
features are added, aka a PSR-1 mode):new SplClassLoader( array( 'Doctrine\Common' => '/path/to/doctrine' )
);Or something like this (if we want the options to be an array):
new SplClassLoader( array( 'ns' => array( 'Doctrine\Common' =>
'/path/to/doctrine' ) ) );For documentation and argument validation, imo the former approach
would be
better.
So what is the status here? thread has been silent for a while.Or a strict mode is added to enable that, then you'll reduce 6
string
function to 2, and still have backward support for PEAR class
naming(w/o
namespace).The url for the RFC is: https://wiki.php.net/rfc/splclassloader
Cheers,
On Mon, Oct 24, 2011 at 7:55 PM, David Coallier davidc@php.net
wrote:Could you open a FR at bugs.php.net and attach the patch to it
please?
Could be easier to track (and the # to the RFC too :)Yeah I'll do that once I have the tests adjusted and once I know
the
patch actually works as expected.--
David Coallier--
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil--
--
Laruence Xinchen Hui
http://www.laruence.com/
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.
"If you use lowerCamelCase on the class names or your namespace, it will
(/should) be exactly like on disk as well."
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.
"(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). - php core doesn't force/favor any coding convention/standard, why should
it do it for PSR-0?
"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. - 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.
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?
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
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,
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 toDIRECTORY_SEPARATORused
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.huI 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 toDIRECTORY_SEPARATORused
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 toDIRECTORY_SEPARATORused
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.huI 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.phpI 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 toDIRECTORY_SEPARATORused
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
But that's besides the point. I just want to emphasize the point that
performance should not be a criteria for justifying it going into the
core...
There also seems to be the perception among some php devs that autoloading
is now the preferred way of loading PHP code.
So adding require() or other explicit dependencies add the top of your
scripts is no longer the appropriate way to do things.
SplClassLoader solves an interoperability problem. Shouldn't it be promoted
as such?
So overall I agree with Anthony, performance shouldn't even be an argument.
If you want to solve a "code loading problem", autoloading everything is far
from a silver bullet and in my opinion not a good solution.
The main question seems to be: does interoperability belong in core?
hi,
I'd to be in favor to include it. However I would like to hear more
from the people behind PSR-0 to be sure that it is actually what is
needed and to complete the RFC (it is rather missing real info,
examples and tests).
Please also update the patch and attach it to the RFC.
Cheers,
On Mon, Oct 24, 2011 at 4:47 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:
Hi internals,
It's been a while since Stas accepted that, but it seems the class
haven't been merged since then.
What's the status of this? Can I expect SplClassLoader in 5.4.0?It seems it was approved, but wasn't merged and thread was lost in space. =(
There's an RFC for it: https://wiki.php.net/rfc/splclassloader
There's a patch for it: https://github.com/metagoto/splclassloaderI'm not 100% sure the patch still works since it's been over 1 year
since it was proposed... =\Cheers,
Hi!
There's a RFC covering this. There's a patch also.
This one seems to have fallen through the cracks?
Well, nobody proposed it in time (especially not the RFC author :)
- The other implementation I could see is to modify spl_autoload to be
able
to pass it a parameter for the auto loading type - right now it will
attempt
to autoload everything lowercase (been brought up a few times).I think the class looks better. I think RFC needs to be expanded with
description of what the class actually does and how, and then if there are
no objections I think we could take it into 5.4.0, since the implementation
already exists.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
I've been following this but not on the internal portions of PSR-0...
Why it is needed:
Currently all of the implementations on the autoloading side is pushed in
through a custom class or function inside of spl_autoload whereas the
registered autoloading takes place. Currently each framework that utilizes
this implements it within their own source code:
- ZF:
http://framework.zend.com/apidoc/1.11/db_Loader_Autoloader.html#%5CZend_Loader_Autoloader - Symfony: https://github.com/symfony/ClassLoader
By standardizing this inside of an extension gains us 2 very major features
(IMO):
- Extension would force the standard but could be extended to add in
various needs in the event there is additional functionality. - Easier for someone to implement PSR-0 without having to create a custom
autoloader elsewhere
The speed of this should give us a slight bump (only slight seeing as w/o
the use of absolute paths apc doesn't really gain us anything).
Overall; it should clean up the various implementations that are scattered
about. Additionally; this should gain greater acceptance and an easier
implementations by people creating their custom frameworks or leveraging
something such as PSR-0.
From the RFC prospective it does seem like many things are missing:
- Examples
- The easiest example being that of a folder structure and class naming such
as in PSR-0 with the instance of the autoloader.
- Use Cases
- Examples of framework cases... additionally extending framework libraries
in separate folders.
Regards,
Mike
hi,
I'd to be in favor to include it. However I would like to hear more
from the people behind PSR-0 to be sure that it is actually what is
needed and to complete the RFC (it is rather missing real info,
examples and tests).Please also update the patch and attach it to the RFC.
Cheers,
On Mon, Oct 24, 2011 at 4:47 PM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:Hi internals,
It's been a while since Stas accepted that, but it seems the class
haven't been merged since then.
What's the status of this? Can I expect SplClassLoader in 5.4.0?It seems it was approved, but wasn't merged and thread was lost in space.
=(There's an RFC for it: https://wiki.php.net/rfc/splclassloader
There's a patch for it: https://github.com/metagoto/splclassloaderI'm not 100% sure the patch still works since it's been over 1 year
since it was proposed... =\Cheers,
On Fri, Jul 15, 2011 at 4:07 PM, Stas Malyshev smalyshev@sugarcrm.com
wrote:Hi!
There's a RFC covering this. There's a patch also.
This one seems to have fallen through the cracks?
Well, nobody proposed it in time (especially not the RFC author :)
- The other implementation I could see is to modify spl_autoload to be
able
to pass it a parameter for the auto loading type - right now it will
attempt
to autoload everything lowercase (been brought up a few times).I think the class looks better. I think RFC needs to be expanded with
description of what the class actually does and how, and then if there
are
no objections I think we could take it into 5.4.0, since the
implementation
already exists.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil--
--
Pierre@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
By standardizing this inside of an extension gains us 2 very major features
(IMO):
But we already have the extension, don't we?
From the RFC prospective it does seem like many things are missing:
- Examples
- The easiest example being that of a folder structure and class naming such
as in PSR-0 with the instance of the autoloader.
- Use Cases
- Examples of framework cases... additionally extending framework libraries
in separate folders.
Yes, the RFC is not really up-to-date or complete. Another thing is I
wouldn't really want to add anything that isn't a bugfix or BC fix or
anything of this nature after RC1 is out. So if there's support for
getting it into SPL, proper RFC, consensus gathering, patch, and all the
process should be complete by Nov. 10, otherwise it's not in for 5.4.0.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
2011/6/27 guilhermeblanco@gmail.com guilhermeblanco@gmail.com:
Hannes,
There's a RFC covering this. There's a patch also.
I do have a few remarks:
- That is not a class loader, that is a loader (also for
interfaces), hence my suggestion s/SplClassLoader/SplLoader/ - PSR-0 is great and it has the merit to exists, however PHP should
remain a bit more independent on a standard perspective. My suggestion
is to name that class accordingly: SplPsr0Loader ? - Optionally, an abstract class or interface might be realized on top
of the SplPsr0Loader and would share common points of different
autoloading strategies. To achieve that we should take different
strategies in mind and see what are the common points.
Regards,
Patrick