SplClassLoader

I couldn't agree more with Anthony. In conjunction with that, I would continue to question the full benefit to the community. How many existing code bases/frameworks out there would implement this in favor of their existing solution?

Will

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 the T_NS_SEPARATOR will 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/