On Fri, Aug 30, 2013 at 6:57 AM, Stas Malyshev <smalys...@sugarcrm.com>wrote:
> 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).
>
For functions people do not commonly use a one-to-one mapping between a
function name and a file, that's true. But there commonly *is* a one-to-one
mapping between a *namespace* and a file. So if you have a function
foo\bar\baz it will be in the file foo/bar.php (which defines all functions
of namespace foo\bar). I think this is a rather common pattern in
functional (or function-heavy) libraries and I use this myself too.
Apart from such a namespace-to-file mapping you can also use the same
approach some people use for classes: Just pregenerate the name-to-file
mappings in an array, then loop up from there (e.g. theseer/autoload). This
is one of the rare autoloading concepts that actually properly works in PHP
(much unlike PSR-0, which fails to honor case-insensitivity).
> 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.
>
I'd assume that this isn't yet the final patch and it will be improved to
make sure that there is no significant performance regression for function
calls not making use of autoloading. This should just be a matter of
inlining the part of the function with the direct hash lookup and avoiding
a duplicate lcname call. (Maybe in the engine just keep the old if
(zend_hash_find(...)) and add an else { autoload(); }.)
Putting autoloading of different entities into one function makes very
> little sense to me - why would the same code load both classes and
> functions?
I don't think it makes much sense to use the same function to autoload
classes and functions, but I think it makes sense to autoload both
functions and constants with the same mechanism, because presumably both
would follow the same naming-convention (e.g. the namespace-to-file mapping
mentioned above). So I think this is a useful feature and I definitely
don't see a reason why we need to explicitly prevent it.
Anyway, I'm +1 on this :) PHP has been neglecting it's functional sides.
The "use function" RFC and this one work on improving this a bit.
Nikita
