Stas,
On Fri, Aug 30, 2013 at 12:57 AM, Stas Malyshev <smalys...@sugarcrm.com>wrote: > Hi! > > > I have created a new draft RFC implementing function and constant > > autoloading in master: > > > > https://wiki.php.net/rfc/function_autoloading > > > > All feedback is welcome. > > I think it is an unnecessary complication. Classes fit autoloader > paradigm nicely, since the usual pattern is one class per one file > (actually recommended in PSR), so it is easy to establish one-to-one > automatic mapping between classes and files (also recommended in the > PSR). But for functions nobody does this. This means that to implement > function autoloader one will need to have a complicated and fragile > logic (since there's no way to ensure this logic would be in sync with > actual content of files containing multiple functions). I don't think that's a fair argument. It's a bit "We don't support function autoloading, so function autoloading doesn't make sense". As far as complicated and fragile logic, as Nikita pointed out, you could put all of your functions inside of a "functions,php" in a particular namespace. Then, with use function, you can capture the missing function call, and cut off the function name, require_once /path/to/namespace/functions.php, and be good. Or, alternatively, you can keep a mapping of function->filename. There's no need or requirement for one-class, one-function or one-constant. Furthermore, I think that's up to the community to decide how to do. They mostly settled on a 1-class-to-1-file rule (which was not the case prior to __autoload/spl_autoload). I am fully confident that they will find a way that makes sense, if given the ability. > Putting autoloading of different entities into one function makes very > little sense to me - why would the same code load both classes and > functions? How would it do that besides ugly switch that just stuffs two > completely different logic pieces into one function for no reason? The > example given in the RFC is certainly not what anybody would actually > want their autoloaders to do, so I fail to see any case for doing it and > for putting loading more than one entity into one function (that given > that autoloading function would be desirable at all, which it still > doesn't seem so for me). > That's why this is a RFC which is up for discussion. That's why this is a draft instead of a proposal. Would you rather see: bool php\autoload_class_register($callback, $prepend)) bool php\autoload_function_register($callback, $prepend) bool php\autoload_constant_register($callback, $prepend) Would you rather having the single autoload regstier, but enforcing that type must be a single type? Would you rather see interfaces? interface php\Autoloader {} interface php\AutoloaderClass extends php\Autoloader { public function loadClass($name); } interface php\AutoloaderFunction extends php\Autoloader { public function loadFunction($name); } interface php\AutoloaderConstant extends php\Autoloader { public function loadConstant($name); } bool php\autoload_register(php\Autoloader $loader, $prepend); The syntax provided in this RFC is a proposal. It's not set in stone. If you don't like it, let's work towards a better one! Thanks, Anthony
