Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125117
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\))
Subject: Re: [PHP-DEV] [Concept] Flip relative function lookup order (global,
 then local)
Date: Fri, 23 Aug 2024 12:14:28 +0200
References: <CAPyj-LCoBY2bPHLmsyONYDbY9aRSraLz5QNskeTiWfpMD0pTSg@mail.gmail.com>
 <c385b525-37f7-446b-aa96-72272ef9e407@app.fastmail.com>
 <CAPyj-LA4kTJTrQZUkn9kNMvWdH6SsFGU5mBO6EcpuUcRpXesgw@mail.gmail.com>
 <d4b18a48-93b0-49c8-821d-f9298e831188@rwec.co.uk>
 <BD6D644E-A90C-49B8-B51A-C9D4C943FDF6@newclarity.net>
 <846D7756-712B-4A7C-9FC6-DB9F858836B8@rwec.co.uk>
 <880ffc27dc9b421407a670c75d5f5ba756870396.camel@ageofdream.com>
 <790534cd-e158-4712-878c-642dfd0e2bad@app.fastmail.com>
 <a0db04a7fa1d9c77b9d2b0110b50a47ef959e98f.camel@ageofdream.com>
 <d26516d7-afaa-4174-81f0-361785908967@app.fastmail.com>
 <d8bf24792d307d07863176772fbf35ec701b6b4b.camel@ageofdream.com>
To: PHP internals <internals@lists.php.net>
In-Reply-To: <d8bf24792d307d07863176772fbf35ec701b6b4b.camel@ageofdream.com>
Message-ID: <63F3CFAA-0D9A-4323-A1A4-0E3544281ECE@cschneid.com>
From: cschneid@cschneid.com (Christian Schneider)

Am 23.08.2024 um 11:34 schrieb Nick Lockheart <lists@ageofdream.com>:
> I think we are all trying to achieve the same thing here.

I'm not sure who "we" and what "same thing" here exactly is.

I recall the following arguments for changing the current situation =
about function look ups:
- Performance
- Function autoloading
- Consistency

Did I miss something big?

First of all I don't think the performance argument holds enough weight =
as I'm very doubtful this impacts performance of a real world =
application in a significant way. And for people *really* hitting this =
problem there is a solution already.
Secondly I am a bit confused about the whole function autoloading =
discussion: There is already a good-enough mechanism (putting them as =
static functions inside a tool class). I just don't consider the hoops =
we have to jump through to get a more "pure" or fine-grained solution =
for a special problem not worth it. As for the "don't use classes for =
static functions" I've yet to see a good argument apart from personal =
preference.
As far as consistency goes I've yet to encounter someone being confused =
about function resolution. But then again I'm not reaching namespaces =
for PHP classes.

While modern tooling possibly can adapt source code to the new style =
efficiently I have to maintain too many installations of PHP projects on =
various hosters to looking forward to that. And the argument that "you =
can just stay on an old PHP version" is just not a feasible solution =
either..

Maybe we should take a step back and reevaluate the pros and cons.=20

- Chris