Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108308
User-Agent: Cyrus-JMAP/3.1.7-781-gfc16016-fmstable-20200127v1
Mime-Version: 1.0
Message-ID: <864594ef-e781-4d98-bbc1-a66330355e33@www.fastmail.com>
In-Reply-To: 
 <BYAPR05MB653585B875D8625B21CF4142DE050@BYAPR05MB6535.namprd05.prod.outlook.com>
References: 
 <DM5PR07MB30670BE1BAF74AAC2B4486DBF9050@DM5PR07MB3067.namprd07.prod.outlook.com>
 <BYAPR05MB653585B875D8625B21CF4142DE050@BYAPR05MB6535.namprd05.prod.outlook.com>
Date: Tue, 28 Jan 2020 22:48:25 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] Re: [VOTE] declare(function_and_const_lookup='global')
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Jan 28, 2020, at 10:03 PM, Theodore Brown wrote:

> The RFC mentions two problems it hopes to solve: a minor performance 
> decrease, and developers having to deal with ambiguity. However, a 
> third problem that I think is just as important to fix is the lack of 
> function autoloading which makes extensive use of namespaced functions 
> unfeasible.

Without weighing in on the RFC itself, I really don't think this statement is true anymore.

Back in the day, sure; autoloading for class-like-things only made functions second class citizens.

However, Composer use is now near-universal for new code.  Composer can load specific files full of functions during autoload just fine, and then the functions are universally available.

That would have been a performance hit, but with opcode caching the hit is minimal.  With preloading in 7.4, even that is reduced to almost zero.

Between those two, having a library that is mostly a pile of namespaced functions that are just always-available is quite reasonable and feasible these days.  Whether it's architecturally good or bad is another question, but I don't think the lack of autoloading is a good excuse anymore.

--Larry Garfield