Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:68695 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 71837 invoked from network); 30 Aug 2013 04:57:20 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 30 Aug 2013 04:57:20 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.115 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.115 smtp115.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.115] ([108.166.43.115:41433] helo=smtp115.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 9D/50-64695-E2620225 for ; Fri, 30 Aug 2013 00:57:19 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp7.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 90E7F1B80AC; Fri, 30 Aug 2013 00:57:15 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp7.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 3D6511B8086; Fri, 30 Aug 2013 00:57:15 -0400 (EDT) Message-ID: <5220262A.6040702@sugarcrm.com> Date: Thu, 29 Aug 2013 21:57:14 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Anthony Ferrara CC: "internals@lists.php.net" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading From: smalyshev@sugarcrm.com (Stas Malyshev) 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