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

Reply via email to