Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124754
Message-ID: <599a445530357d080cb59c9443cacd5cfd5da82f.camel@ageofdream.com>
Subject: Re: [PHP-DEV] [RFC] Add Directive to Make All Namespaced Function
 Calls Global
To: internals@lists.php.net
Date: Mon, 05 Aug 2024 04:22:08 -0400
In-Reply-To: <CAPyj-LC4-euT3ddEXMUv8jdOONrtFu16se4zZ38yrt+oaA845g@mail.gmail.com>
References: 
	<USzt7tZZlO1DmAbSTLhD-bqa23FqZn0zk2aah8Ndxgk9c7RY5PefQ8MjbYPUYAzr2_m4Cf-5AI4PuNBTS84rim_FNS6RaT-cWSv714HEvvU=@gpb.moe>
	 <1a88918e-e808-d778-45e1-53797660e093@php.net>
	 <CAPrKfG5Cw_nU7g7FR+t4C1-YZ8CDsDO_-sRs=yEsHO5kCTZL+A@mail.gmail.com>
	 <c03eb187-bd21-4a4b-9faf-8d0243eaa994@varteg.nz>
	 <aa6bc7aa-28d9-40ca-974f-65075adb6199@rwec.co.uk>
	 <3563cf9b-8eab-4c82-b525-a5d2f9a767bb@varteg.nz>
	 <38920A4B-790D-48C7-B2F6-C49D3F506232@rwec.co.uk>
	 <0824789d-0e36-4628-85c1-4b8d9b7f86af@varteg.nz>
	 <ab8c974a-c31c-4ff6-974d-0a8c962d5e22@app.fastmail.com>
	 <2244a37f-8c51-448d-8a56-329ff32e6470@bastelstu.be>
	 <AE6EAAFA-3E8F-4B7C-877F-D84FBA8178C5@newclarity.net>
	 <fc46131c-9f12-4601-b197-f4d66b79f2f8@varteg.nz>
	 <D748C182-20C0-4BE4-859E-FBE86BB93524@newclarity.net>
	 <0e1a21ddef3c7da17a3539b92d5f442763f4b1f8.camel@ageofdream.com>
	 <CAPyj-LD02XrZ4F6ZqG0PNLrrfekBHiiz+S24v5nv_9xgW4UKUg@mail.gmail.com>
	 <5f1da5195e2aea7ec41e95ff4354f50b1717d3cf.camel@ageofdream.com>
	 <CAPyj-LDhFFv=B-324YZDUv8BdV8npj6npLn9jxv3reA9SoGjqw@mail.gmail.com>
	 <a97242032874e73480c2883e23745a1691ff261a.camel@ageofdream.com>
	 <CAPyj-LC4-euT3ddEXMUv8jdOONrtFu16se4zZ38yrt+oaA845g@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.4-2 
Precedence: bulk
MIME-Version: 1.0
From: lists@ageofdream.com (Nick Lockheart)


> >=20
> > I did not intend for all unqualified calls to become global, unless
> > the new directive is present.
>=20
> Sorry, my language was not precise enough. Your proposal suggests
> making unqualified calls global when the directive is present,
> whereas my proposal suggests keeping local scope as a fallback, hence
> the two not being compatible.

Keeping local scope as a fallback would still require an NS lookup
opcode.

My proposal is that there still be an NS lookup as the default
behavior, but allow an optional override.

That is, users would have three options:

(1) resolve all unqualified function names to global (no NS lookup)
(2) resolve all unqualified function names to local (no NS lookup)
(3) Use the default behavior, which at present, is local first, then
global, with a namespace lookup. (no change to user code, keeps BC)

Your proposal reverses the order of the default NS lookup from local
first to global first.

That's not mutually exclusive.

If my proposal *and* yours were *both* accepted, users would have these
options:

(1) resolve all unqualified function names to global (no NS lookup)
(2) resolve all unqualified function names to local (no NS lookup)
(3) Use the default behavior, which would now be global first, then
local, with a namespace lookup. (no change to user code, keeps BC
working, but changes the default automatic lookup order)

I believe that my propsal also helps yours be more viable, too. Because
if your proposal was accepted alone, and the NS lookup order changed,
then it would no longer be possible to do unit testing with stubs that
replace built-in functions, UNLESS there was also an option for
developers to instruct the compiler to use local functions over global
ones.


>=20
> What I'm saying is that:
>=20
> 1. If the vote fails, it might have been because some people don't
> want opt-in behavior. Niels just voiced this opinion.

Every token added to a PHP file is opt-in behavior that changes how the
parser works.

> 2. If the vote is accepted, it would void my suggestion, because it
> is not compatible with the conditions laid out in your proposal.

I don't see them as being incompatible at all, they would actually work
together. An automatic performance improvement for everyone without any
BC breaks or code changes, plus a new option that gives advanced
developers a new tool to write cleaner class code, and enable advanced
unit testing tools to work.

>=20
> A vote with multiple options to pick an approach (opt-in through some
> directive, hard BC break, flipping lookup order, nothing at all)
> might be more appropriate.


A vote has not been called, and an RFC is supposed to be amended in
response to comments and discussion.

I think something needs to be at least as formal as an RFC or people
won't take it seriously enough to contribute feedback.

I'm trying to start a discussion on this and get some momentum so that
we can hopefully implement something in a near future version.

Please, let us discuss.