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). Moreover, since this replaces a simple hash lookup with additional two function calls (and also other operations included in those) everywhere in the engine, it will also have performance impact of one of the most frequently used operations in the engine - function calls - while providing absolutely no benefit for 100% of existing code and 99.99% of future code. 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). It is -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php