Re: SPLClassLoader RFC Thoughts And Improvements

Well, the problem with adding methods later is that it will fatal any class that implements the old one. A big no no. You could get around that by doing something like traversable. Provide an empty and non usable core SplAutoloader interface which is typehintable. Then add a child SplClassAutoloader interface which defines loadClass. That way, in the future a new child could be added SplFunctionAutoloader which defines loadFunction. By separating them, you maintain type hinting while enabling backwards compatibility with existing code... Just a thought. On Nov 10, 2011 6:13 PM, "David Muir" <davidkmuir@gmail.com> wrote: > Surprised to say that I agree on just about everything you mentioned. I > would however love to see a useful autoloader included in core. I have > only one comment below. > > 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). > > IMO, the interface should just define loadClass($class). It means that > spl_autoload_register has a fixed target for loading classes, and if we > want to support autoloading functions or whatever else later on, a new > interface can be added that would define the appropriate method eg. > loadFunction($function). > > Cheers, > David > >