David Sorry, I just RE read your reply. that's basically what you said, so in essence I agree...
Anthony On Nov 10, 2011 6:29 PM, "Anthony Ferrara" <ircmax...@gmail.com> wrote: > 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" <davidkm...@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 >> >>
