Guilherme et al,
Since you asked me for feedback on how I would suggest improving the
RFC, so here it goes...
I think I need to make one thing clear first. I don't think that I
can vote yes for this RFC in principle (I just don't agree this
belongs in core). However, with that said if the RFC was clarified
and takes care of the issues that are listed here, I will stop
actively opposing it and may even consider removing my no vote. I say
this not because I want to emphasize anything, but because I want to
make sure that expectations are managed and that nobody is going to
get mad at me for not changing my vote if everything here is
completed.
Now, with that disclaimer behind us, let's move on to how I would like
the RFC changed (In no particular order):
1. The implemented solution **must** under all circumstances play nice
with other autoloaders and code. This means that it should **never**
throw an error under any circumstances. In order to achieve that,
three things would need to happen:
a) The code that includes the file would need to be wrapped in a
file_exists call to ensure that the include would actually work. This
will prevent issues with different tree structures causing errors to
be thrown.
b) The code that includes the file should be changed to require_once
to eliminate including the same file twice when different classes map
to the same file. For example, this should not fail (assuming both
classes are not in the same file):
new \Foo\Bar\Baz;
new \Foo\Bar_Baz;
Both map to the same file, but are distinct classes in PHP.
By changing it to require_once, it'll realize it already included the
file and then skip over that and let another class have its shot.
c) No exceptions, warnings, notices, etc should be thrown under any
circumstances *when loading a file*. You could have it throw an
exception (or warning, whatever) if the path passed to the constructor
is invalid, but when loading a class it should never throw one (which
would cause issues or prevent other autoloaders from functioning
properly). And considering that we can use ErrorExceptions, raising
PHP Errors would cause the same problem. Note that this does not
affect the included file as that can do any error. Just the
autoloader itself shouldn't. This means that setMode should be
removed since it would cause the autoloader to stop from "playing
nice". This seems like user choice, but what if a library ships in
normal mode (which is default now) and these issues occur? My view is
that it should *always* be silent. PHP has mechanisms for handling
not-found classes. Autoloading is one, and fatal errors is another.
It's not the job of the autoloader to throw errors...
2. The RFC *needs* to address how the implementation may/should evolve
over time. I know it appears that PSR-0 is 100% sufficient now, but
there will come a time when it is no longer so. A perfect example of
that is the discussion that was on the list in the past few
weeks/months about adding function autoloading. What happens at that
point, how could/should this implementation adapt and evolve? I would
suggest not tackling specific possible changes, but more on how
changes would be handled. Would you add new methods? New classes?
Change APIs? How would you maintain backwards compatibility? Can you
maintain BC?
3. The RFC should at least address how other autoloading schemes would
fit into the picture. If we add this PSR-0 style autoloader, can
other style autoloaders be included? I know some will say "do any
others need to be included". But what about things like the automap
extension (which maps classes to files via an array list)? How should
that fit into the picture?
4. The RFC should avoid implementing any pattern or style that may
make future feature addition difficult or pose risks towards such. An
example would be implementing an interface for the autoloader which
defines something like load($class). The problem there is that if
function autoloading is added, the interface won't be able to support
it. So it's stuck in a hard place between changing an implemented
interface (which will bork code significantly on update) and adding a
new interface (which would be the lesser of evils, but would just add
to the deprecated cruft).
5. The RFC *must* talk about how user-land classes can and should
extend this core implementation. For example, if users wanted to
change the behavior, can they just subclass and override certain
methods? Are there any "dangerous" methods that shouldn't be
overriden? Should any of the C functions (such as get_filename) be
implemented as a method (possibly protected) to allow for extending
classes to change that behavior? The important thing is that this
will need to be documented prior to release, and it will make our
lives easier documenting recommended best practices if it's already at
least discussed in the RFC.
6. The RFC should contain a proposed patch (or at least reference
implementation) prior to being voted upon. That way everybody knows
what's being voted on, rather than a wandering text. Because
ultimately it doesn't matter what's written in the RFC as the code
will always win (code wins over docs under all circumstances, as code
doesn't lie). That patch should not change fundamentally (aside from
tweaks or bug fixes) after the vote starts. If it does change, the
vote should be restarted (or at least extended with a note made about
it) as it's not really fair to ask people to vote on a target, and
then move that target.
Now, one other point. You might want to consider adding __invoke()
support so that you don't need to change spl_autoload_register at all.
That way, you could support spl_autoload_register(new
SplClassLoader()); without needing to touch existing functionality...
Thoughts?
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
