Hi,
I'm fine with the most of the implementation. But I have some
suggestions to optimize it.
1. The interface should be named SplClassLoader and the register and
unregister methods should be removed.
It should be possible to define class loader implementations without
registering them as autoloader because autoloading isn't the only way to
load classes. A class loader could as example return the ReflectionClass
instance for the loaded class. I think the current interface is to
restrictive in this case. As compromise it would be possible to define a
SplClassAutoloader interface too. This interface extends the
SplClassLoader interface and defines the methods register and
unregister.
interface SplClassAutoloader extends SplClassLoader {
public function register($prepend = false);
public function unregister();
}
As a side note, the two interfaces doesn't violate the Single
responsibility principle.
I know the reference implementation is named as SplClassLoader but this
should be renamed into SplDefaultAutoloader or SplPsrAutoloader if
implements the SplClassAutoloader or as SplPsrClassloader or
SplDefaultClassloader if implements the SplClassLoader interface.
2. The function spl_autoload_register() should accept all
SplClassLoader implementations.
I know it's already possible with the following syntax:
$classLoader = new MyCustomClassLoader();
spl_autoload_register(array($classLoader, 'load'));
But the following syntax seems more consistent to me:
$classLoader = new MyCustomClassLoader();
spl_autoload_register($classLoader);
Christian
Am 09.11.2011 02:23, schrieb guilhermebla...@gmail.com:
For all those interested, I implemented what I referred as item 2:
<quote>
After some thought it makes sense, but only if interface then defines
the setMode prototype.
The background for this is supported if the user decides to enhance
the base class to support caching, requiring the injection of the
Cache layer in constructor. If it's part of the interface, it cannot
be changed.
</quote>
RFC is now updated covering this. If you have more questions or
suggestions, feel free to tell me.
On Tue, Nov 8, 2011 at 3:55 PM, guilhermebla...@gmail.com
<guilhermebla...@gmail.com> wrote:
Hi Nikita,
Thanks.
It's your option and I won't fight. But it seems my proposal is not
yet 100%.
Some things I have either identified or people have reported.
1- Remove ->register() and ->unregister(), and make the
spl_autoload_register to support SplClassLoader.
I'm really +0 on this one.
But since the proposal covers an OO approach for autoload, it makes
sense the registering is pat of the available API, not in procedural
land.
2- Remove constructor prototype in interface
After some thought it makes sense, but only if interface then
defines
the setMode prototype.
The background for this is supported if the user decides to enhance
the base class to support caching, requiring the injection of the
Cache layer in constructor. If it's part of the interface, it cannot
be changed.
I took this example after looking at Symfony's
ApcUniversalClassLoader:
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/ClassLoader/ApcUniversalClassLoader.php
What do you think about these 2 points?
Even if you're against the proposal, for sure you can still help to
make it consistent.
Cheers,
On Tue, Nov 8, 2011 at 3:39 PM, Nikita Popov
<nikita....@googlemail.com> wrote:
On Tue, Nov 8, 2011 at 6:28 PM, guilhermebla...@gmail.com
<guilhermebla...@gmail.com> wrote:
Because there's no need to bring to C a single foreach.
Also, if you re-read the RFC, you'll see that SplClassLoader is
extendable for personalized developer needs, such as an addAll or
an
APC lookup.
After your changes the RFC looks much more decent. I am still
opposed
to the idea of this going into core (mainly because there is no
necessity), but now the implementation is somewhat more useful.
Nikita
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil
--
Guilherme Blanco
Mobile: +55 (11) 8118-4422
MSN: guilhermebla...@hotmail.com
São Paulo - SP/Brazil
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
