November 6, 2011

Discussion about the PSR-0 autolaoder in PHP core

Currently there is an active discussion on the PHP internal list about implementing the PSR-0 draft in the PHP core. The provided patch adds a class called SplClassLoader to the SPL extension. This class has the ability to autoload classes which follows the PSR-0 draft.

First let me say that I'm not against PSR-0, I think it is the right way to accomplish interoperability between different projects. But I'm against including the class in the proposed form into the PHP core. Not because of all the things said by other developers, for me its more a design decision.

Design decision?

In my opinion the class violates against one of the fundamental OOP principles. The principle what I mean is the Single responsibility principle introduced by Robert C. Martin. This principle says that a class should only have one responsibility, and that responsibility should be entirely encapsulated by the class. But the class provided by the patch shares two responsibilities. The first is to load classes which follows the PSR-0 draft and the second is to load classes automatically. So following this principle the class SPLClassLoader should only load classes. The autoloading part should be implemented in an additional class.

Another important thing is that the PSR-0 draft says not how classes should be loaded. The draft only describes how classes should be named so that they can be loaded across different projects. The proposed patch is only one possible variant to load classes which follows the PSR-0 draft. There exists some other variants:
  • Classes can be loaded from PHP include path
  • Classes can be loaded from a static map
  • Class paths can be cached
  • ...
All these variants can be PSR-0 conform. So for me it's bad design to push one of the possible solutions used by some developers in the core.

Any suggestions?

Yes. A suggested above, one possible solution would be to split the concerns into separate parts. The first part should be an interface ClassLoader: The second part should be an ClassAutoloader class itself: Note that this is only one possible solution of an autoloader class.

What are the benefits?

Now that we have split the proposed class in their concerns, it would be possible to implement all conceivable ClassLoader implementations in userland or fair enough in core. The ClassAutoloader class provides an simple interface for registering the preferred ClassLoader implementation, regardless of whether if it's PSR-0 or not.

Now, what is your position?

I'm not sure if PHP should implement all possible ClassLoader solutions(including the PSR-0 variants). Because they can all be implemented in userland and I think the performance boost, if implementing it in core, is marginal.

But I think all developers out there would be benefit from an object oriented interface to register ClassLoader implementations for autoloading. So it's easy to share class loaders across other projects because of the consistent interface. This is more interoperability as including a single class loader implementation in core.

3 comments:

  1. "The first is to load classes which follows the PSR-0 draft and the second is to load classes automatically."

    The automatic part is handled by the spl_autoload stack. The register() method could be a violation, and your ClassLoader interface would remove the need for a register method if spl_autoload_register() accepted ClassLoader implementations.

    I don't see the point of your ClassAutoloader class though.

    ReplyDelete
  2. Yes, you are right. If spl_autoload_register() accepts ClassLoader implementations, the ClassAutoloader wouldn't be needed. But I talk about object oriented design and the procedural call doesn't really fit into this paradigm.

    ReplyDelete
  3. Please revisit the RFc, it was updated! =)

    ReplyDelete