Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68698
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.192.175 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <5220262A.6040702@sugarcrm.com>
References: <CAAyV7nFRfuu0dGnu0FV1ehkqwQR6=dUFSHMP=6CJsAVWghCADg@mail.gmail.com>
	<5220262A.6040702@sugarcrm.com>
Date: Thu, 29 Aug 2013 23:51:34 -0700
Message-ID: <CAESVnVr18CAAqr4oZHB9KKnAs9Ry-gQFsR2icE8XxLr8w+knNQ@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Anthony Ferrara <ircmaxell@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b111915487b2c04e524a775
Subject: Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
From: pollita@php.net (Sara Golemon)

--047d7b111915487b2c04e524a775
Content-Type: text/plain; charset=ISO-8859-1

> 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 disagree on the basis that namespaced functions/constants *do* fit the
same autoloading paradigm.

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.
>
> Those function calls would only kick in if the function/constant wasn't
already defined, which will be the exception case, so perf isn't a strong
argument.


> 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 I agree with 100%.

-Sara

--047d7b111915487b2c04e524a775--