Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68702
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5220262A.6040702@sugarcrm.com>
References: <CAAyV7nFRfuu0dGnu0FV1ehkqwQR6=dUFSHMP=6CJsAVWghCADg@mail.gmail.com>
 <5220262A.6040702@sugarcrm.com>
Date: Fri, 30 Aug 2013 09:29:55 +0200
Message-ID: <CALtuQzAOBfb_gSWAYW903=ymUL=T3+0vpQnbX9GxPodv8O14Bw@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=e89a8f3baedfcf499d04e5253274
Subject: Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading
From: krebs.seb@gmail.com (Sebastian Krebs)

--e89a8f3baedfcf499d04e5253274
Content-Type: text/plain; charset=ISO-8859-1

2013/8/30 Stas Malyshev <smalyshev@sugarcrm.com>

> 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).


Autoloading was introduced long before PSR-0 and PSR-0 is also only a
recommendation. So saying "class autoloading was easily introduceable,
because there was _always_ a class<->file mapping" is somehow misleading.


> 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).
>

This is the same complicated and fragile logik you need for class loading.
For example compared to PSR-0 functions could be implemented in a file
named after the namespace. An autoloader would be very similar to every
already existing PSR-0 class loader.


>
> 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
>
>


-- 
github.com/KingCrunch

--e89a8f3baedfcf499d04e5253274--