No description provided.
JLoader : Files located at the root path, where the prefix is registe…
…red, cannot be autoloaded.
I can see how this is useful but I'm afraid of the performance implications. In some testing I did we spend up to 20% of the execution time in the autoloader. If we add more it certainly won't help.
I let other s judge whether it's worth the trade off, but frankly I don't see the big deal with following our folder strcuture. We could put the factory into a factory folder and it would be autoloadable too.
I added the code at the end, I don't think it changes a lot the current execution time : it adds one variable allocation, and two when there is only one part in the class name.
The if is never executed for platform classes, because there is only one lookup path.
Well it is for all legacy classes. For example in the Joomla CMS we have 3 autoloaders for J prefix so this code would be executed twice in the worst case.
Another thing that just occurred to me is that with this patch we don't have a 1:1 mapping of class names and file paths anymore. Again not a big deal but something to consider (and document).
Edith: The thing is also not the variable but the file_exists() call.
Yes, in the case of the CMS it can add two file_exists calls in some cases when there is only one part.
What I was thinking also regarding my namespace loader pull request is eventually to have more than one autoloader.
In this case, JLoader would stay like that to auto load the core, and we can have a JLoaderNamespace, and eventually an other Loader with this feature.
It can allow people to use the auto loader they want for their application/components without making the core execution slower, and avoid to register more methods by default to the spl autoloader stack.