Re: RFC __autodefine / spl_autodefine

On Monday, December 06, 2010 6:59:08 pm Ross Masters wrote: > Hi Sebastien, > > > __autoload() should die (as in get deprecated ASAP and later removed) > > I couldn't find anything about your opinions on this so I was wondering if > you could elaborate. Do you consider autoloading as a bad practice or just > that spl_autoload_register should be used to add relevant > functions/closures? __autoload() works fine if you have exactly one implementation for your entire system with exactly one set of logic for how to map a class name to a file name. As soon as you try to mix two different libraries together, fatal error. spl_autoload() does not suffer from this short-sighted problem but accomplishes the same goal in a much more robust fashion. Any new meta-auto-load mechanism should forego the dead-end that is a single unique __auto*() function and just use a design that actually works, aka spl_autoload() or similar. With that said, I like the idea of generalizing autoload to include functions et al. Autoloading functions would make my life a lot easier. :-) To be fair, though, half of the potential benefits the OP listed are already solved by using a version control system. Any version control system. If you're still having collisions at the file level when two people work on the same file it's because you're an idiot and are not using version control (or the changes touch each other, in which case this proposal wouldn't help you anyway). The main advantage of this proposal would be lazy-loading of functions. I don't think autoloading methods makes any sense since classes cannot be split between files anyway. I'm not entirely sure what else is actually reasonable to autoload. Classes, Interfaces, Functions, and Traits make up the scope of first-class code structures, don't they? Autoloading a variable doesn't even make sense to me, and include files are already handled by include[_once]. --Larry Garfield