Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125130 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 1A34B1A00BD for ; Fri, 23 Aug 2024 12:17:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1724415555; bh=qEk4tNLh33BQV3rk4DJ8Q1AbLsMjUCQsGVtwnal4z/Y=; h=Date:From:To:In-Reply-To:References:Subject:From; b=lj7EUJCkl4lFXUnEc9I2yHjyDGkAGOTmEu40bR05Xtn86sJA32iiCI+LlchfY/uh2 dujVescPyZz+c9fmIkcS2dLIw3kAX2vL45KGezTrqiUMRKvjUABgp15Y/76qIR56ny d7Sb7E0jaym+Lexemz6vJ+qC/U30miOqIbEHdMsy8DxlEKpEtcZbrOK9448dWypapK F0UXKu2DtVQ2pknB9vFi9Ibn8XC/n8MaD8pGGGc5RTYMwdMu02212RZiUt0K3JPOIl HUNr9mHZMYLT3FCWrbx5aj9HiWul+QG56HgtiNeNIteY1Plfnp/5D07f8pArE5cgIn nSHuzAX/3Sm8A== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B9476180055 for ; Fri, 23 Aug 2024 12:19:12 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from fhigh4-smtp.messagingengine.com (fhigh4-smtp.messagingengine.com [103.168.172.155]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 23 Aug 2024 12:19:10 +0000 (UTC) Received: from phl-compute-03.internal (phl-compute-03.nyi.internal [10.202.2.43]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 594DC1151CB0 for ; Fri, 23 Aug 2024 08:17:19 -0400 (EDT) Received: from phl-imap-09 ([10.202.2.99]) by phl-compute-03.internal (MEProxy); Fri, 23 Aug 2024 08:17:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1724415439; x=1724501839; bh=4e2Uw/tKf/ OrwGlzk0XQ/Q5xNbTSIWwhXnFPsHuHKfQ=; b=a2MIFKeu5piRAQ8nLsln0yaJbu 2vJLlu4jx0GAdThnKdIYCVkkQvyNk20S7PsAP+gPZf4f9RN0sBeOuo2Rsn+CwFO+ IeJdmgnyHhwkWRRHQjyi+Sx37MX6AeBQ4a4IFnFI8Qv3QVaCjFm7uv9GwRO0RkqG B5Kia+KsnzOO0lZPV+1v8MZerMiwjMTZR3zdRKcyQyb2vZb7lrwEiGNuJVuUQZMO 9fFX+f0xHY8rpwShsLLYlHazh/moccE5a+Jq5yP/WjGMM0jZl9RO7UbcZQyL8Mtb xelMqG33ZiVhUZ4FZ2xwFgMmP7t+1WF6aJSBUGh6yTBOAU+f1OCvI7957RLQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1724415439; x=1724501839; bh=4e2Uw/tKf/OrwGlzk0XQ/Q5xNbTS IWwhXnFPsHuHKfQ=; b=h0+O9ZiLrRMhgd5IJtjmzjERKkXMkkfOieRfh2Ztw3lX IkrBgb1n48Sc/f9iYkZeMCLwhUuRX7XrYWMfHQz2KIMUV1Nen0Gk6Ow6vaMLiB7n lXcx0uXKnhUJC3ht+1tyhzTBjUgcFwzbw7HA89zVrr+gsfK2/NsOcOrdAUezIwU0 jR/KR5tyyAa/aZ5Wl61v8ILnZgSIxMrXelEc/Sf8Xd+VT40IEFr03I8PYE/b0BFX DKAYjaLbk9tdMvaTc0Xx+8kZ3PyZlwBcK6kKbuE2MmurWaAfs882aDpzjWep5ACQ PMsnSdav4PTCYpokKZ/axq0AZCS5pz/h/v9ccl268g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddruddvvddghedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefoggffhf fvkfgjfhfutgesrgdtreerredtjeenucfhrhhomhepfdftohgsucfnrghnuggvrhhsfdcu oehrohgssegsohhtthhlvggurdgtohguvghsqeenucggtffrrghtthgvrhhnpedtueejtd ethfeulefhtdelieduteelffdtudelheffgedtieehhfelieejgfevgeenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrohgssegsohhtthhlvg gurdgtohguvghspdhnsggprhgtphhtthhopedupdhmohguvgepshhmthhpohhuthdprhgt phhtthhopehinhhtvghrnhgrlhhssehlihhsthhsrdhphhhprdhnvght X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1C42D780065; Fri, 23 Aug 2024 08:17:19 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 Date: Fri, 23 Aug 2024 14:16:57 +0200 To: internals@lists.php.net Message-ID: In-Reply-To: <8086e7cf5061129eb002317b30aad4bb25811a1a.camel@ageofdream.com> References: <21D6F160-5EAE-44FA-907B-E1DAAC1B8D75@rwec.co.uk> <8086e7cf5061129eb002317b30aad4bb25811a1a.camel@ageofdream.com> Subject: Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then local) Content-Type: multipart/alternative; boundary=e145c706c1ee40ddaa73c85d49cc4134 From: rob@bottled.codes ("Rob Landers") --e145c706c1ee40ddaa73c85d49cc4134 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, Aug 23, 2024, at 11:27, Nick Lockheart wrote: > On Fri, 2024-08-23 at 09:16 +0100, Rowan Tommins [IMSoP] wrote: > >=20 > >=20 > > On 23 August 2024 01:42:38 BST, Nick Lockheart > > wrote: > > >=20 > > > >=20 > > > > BUT, if people already complain about "\" being ugly, having to > > > > write > > > > "namespace\" is going to make them REALLY grumpy... > > > > So maybe at the same time (or, probably, in advance) we need to > > > > come > > > > up with a nicer syntax for explicitly referencing the current > > > > namespace. > > >=20 > > > namespace foo using global functions; > > >=20 > > > - or -=20 > > >=20 > > > namespace foo using local functions; > > >=20 > > >=20 > > > Tell PHP what you want at the per-file level. > >=20 > >=20 > > This doesn't seem mutually exclusive to me. If you have a file where > > you've opted for "using global functions", you might want a way to > > reference a function in the current namespace.=20 >=20 > Correct, so if you use the example: >=20 > namespace foo using global functions; >=20 > you can write: >=20 > array_key_exists(); >=20 > and it will be resolved as global without a namespace lookup and will > use the dedicated opcode. >=20 > But if you need to use a local function you can do: >=20 > \foo\sort(); >=20 >=20 > The proposed global/local declaration as part of the namespace > declaration just turns off namespace lookups and sets the default > resolution for **unqualified** names. >=20 > Fully qualified names are not affected. >=20 >=20 > > It also doesn't address my other point, that having global as the > > default mode (even if we provide an option for local) is much less > > disruptive to existing code. >=20 >=20 > They are compatible, but related decisions. >=20 > I think it would be easier for people to accept a new PHP version where > unqualified names were always global, if we also had an option to make > local/namespaced the default resolution for *unqualified* names, on a > per-file basis, for those who need that. >=20 >=20 > Thus, there are multiple decision points: >=20 > 1. Should we do namespace lookups on unqualified function calls at all? >=20 > 2. If yes to 1, should we lookup in global first or local first? >=20 > 3. Regardless of 1 or 2, should we let developers explicitly specify a > behavior for unqualified calls in the namespace declaration? >=20 > 4. If yes to 1, should the behavior of namespace lookups change for > user-defined functions vs PHP built-in function names? >=20 >=20 > These aren't mutually exclusive, but they all work together to create a > complete behavior. >=20 > There are several ways that the above options could be combined: >=20 >=20 >=20 > ### OPTION ONE ### >=20 > Using a regular namespace declaration still does an NS lookup, in the > same order, just like it normally works now. >=20 > That means that code that uses: >=20 > namespace foo; >=20 > will behave exactly the same as today, with no BC breaks. >=20 > Developers using the new PHP version could opt-in to explicit namespace > behavior with: >=20 > namespace foo using global functions; >=20 > or >=20 > namespace foo using local functions; >=20 > In both cases, *fully-qualified* names still work the same. >=20 > Only *unqualified* names are affected by this directive, and they use > local only or global only, depending on the declaration. >=20 >=20 >=20 > ### OPTION TWO ### >=20 > Namespace lookup is removed from a future version of PHP. >=20 > Code that uses the current namespace declaration:=20 >=20 > namespace foo; >=20 > will assume that all unqualified function calls are global scope. >=20 > To use a function in the local namespace, it can be fully qualified > with: >=20 > \foo\MyFunction(); >=20 >=20 > But, developers could also write: >=20 > namespace foo using local functions; >=20 > And all unqualified function names would be resolved to local at > compile time. Global functions could still be accessed with a `\` if > this directive was used: >=20 > \array_key_exists(); >=20 >=20 >=20 > ### OPTION THREE ### >=20 > Namespace lookup is removed from a future version of PHP. >=20 > Code that uses the current namespace declaration: >=20 > namespace foo; >=20 > ...will assume that an *unqualified* function name is a global function > *IF* it is a PHP built-in function. >=20 > Otherwise, *unqualified* function names that are *not* PHP built-in > functions will be presumed to be local to the namespace. >=20 > With Option Three, developers can still fully-qualify their functions: >=20 > \foo\array_key_exists(); >=20 > ...to override a built-in name with a user function in the current > namespace. >=20 > Likewise, a fully-qualified: >=20 > \MyFunction(); >=20 > called from inside a namespace will still call the global function. >=20 > Only unqualified names are affected. >=20 > As an additional optional feature of Option Three, developers can > change this behavior with: >=20 > namespace foo using global functions; >=20 > or >=20 > namespace foo using local functions; >=20 >=20 > Only *unqualified* names are affected by this directive, and they use > local only or global only, depending on the namespace declaration. >=20 > In both cases, *fully-qualified* names still work the same. >=20 >=20 >=20 > Of course, there are many other possibilities that can be mixed-and- > matched. >=20 I personally would find option 3 to be the best of both worlds, and you = don't even need the `namespace ... using ... functions` stuff. =E2=80=94 Rob --e145c706c1ee40ddaa73c85d49cc4134 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Fri, Aug 23,= 2024, at 11:27, Nick Lockheart wrote:
On Fri, 2024-08-23 at 09:16 +0100, Rowan Tom= mins [IMSoP] wrote:
> 
> 
> On 23 August 2024 01:42:38 BST, Nick Lockheart <lists@ageofdream.com>
> wrote:
> > 
> >= > 
> > > BUT, if people already complain= about "\" being ugly, having to
> > > write
<= /div>
> > > "namespace\" is going to make them REALLY grump= y...
> > > So maybe at the same time (or, probabl= y, in advance) we need to
> > > come
> > > up with a nicer syntax for explicitly referencing the c= urrent
> > > namespace.
> >&n= bsp;
> >    namespace foo using global fun= ctions;
> > 
> > - or -&nbs= p;
> > 
> >    na= mespace foo using local functions;
> > 
> > 
> > Tell PHP what you want at= the per-file level.
> 
> 
> This doesn't seem mutually exclusive to me. If you hav= e a file where
> you've opted for "using global functio= ns", you might want a way to
> reference a function in = the current namespace. 

Correct, so if= you use the example:

    na= mespace foo using global functions;

you can= write:

    array_key_exists= ();

and it will be resolved as global witho= ut a namespace lookup and will
use the dedicated opcode.

But if you need to use a local function you = can do:

    \foo\sort();
=


The proposed global/local decla= ration as part of the namespace
declaration just turns off= namespace lookups and sets the default
resolution for **u= nqualified** names.

Fully qualified names a= re not affected.


> It als= o doesn't address my other point, that having global as the
> default mode (even if we provide an option for local) is much les= s
> disruptive to existing code.


They are compatible, but related decisions.

I think it would be easier for people to accept a= new PHP version where
unqualified names were always globa= l, if we also had an option to make
local/namespaced the d= efault resolution for *unqualified* names, on a
per-file b= asis, for those who need that.


Thus, there are multiple decision points:

1. Should we do namespace lookups on unqualified function calls at all= ?

2. If yes to 1, should we lookup in globa= l first or local first?

3. Regardless of 1 = or 2, should we let developers explicitly specify a
behavi= or for unqualified calls in the namespace declaration?
4. If yes to 1, should the behavior of namespace lookups cha= nge for
user-defined functions vs PHP built-in function na= mes?


These aren't mutually e= xclusive, but they all work together to create a
complete = behavior.

There are several ways that the a= bove options could be combined:


<= div>
### OPTION ONE ###

Using= a regular namespace declaration still does an NS lookup, in the
same order, just like it normally works now.

That means that code that uses:

&n= bsp;   namespace foo;

will behave= exactly the same as today, with no BC breaks.

<= div>Developers using the new PHP version could opt-in to explicit namesp= ace
behavior with:

 &nbs= p;  namespace foo using global functions;

<= div>or

    namespace foo usi= ng local functions;

In both cases, *fully-q= ualified* names still work the same.

Only *= unqualified* names are affected by this directive, and they use
local only or global only, depending on the declaration.
=



### OPTION TWO ###
=

Namespace lookup is removed from a future vers= ion of PHP.

Code that uses the current name= space declaration: 

   = namespace foo;

will assume that all unqual= ified function calls are global scope.

To u= se a function in the local namespace, it can be fully qualified
with:

    \foo\MyFunct= ion();


But, developers could= also write:

     names= pace foo using local functions;

And all unq= ualified function names would be resolved to local at
comp= ile time. Global functions could still be accessed with a `\` if
this directive was used:

  = ;  \array_key_exists();



### OPTION THREE ###

Namesp= ace lookup is removed from a future version of PHP.

Code that uses the current namespace declaration:

    namespace foo;

...will assume that an *unqualified* function name is a global fu= nction
*IF* it is a PHP built-in function.
<= br>
Otherwise, *unqualified* function names that are *not* PHP= built-in
functions will be presumed to be local to the na= mespace.

With Option Three, developers can = still fully-qualify their functions:

 =    \foo\array_key_exists();

...to= override a built-in name with a user function in the current
<= div>namespace.

Likewise, a fully-qualified:=

    \MyFunction();

called from inside a namespace will still call the = global function.

Only unqualified names are= affected.

As an additional optional featur= e of Option Three, developers can
change this behavior wit= h:

    namespace foo using g= lobal functions;

or

    namespace foo using local functions;
<= div>

Only *unqualified* names are affected = by this directive, and they use
local only or global only,= depending on the namespace declaration.

In= both cases, *fully-qualified* names still work the same.
=


Of course, there are many o= ther possibilities that can be mixed-and-
matched.


I personally would fin= d option 3 to be the best of both worlds, and you don't even need the `n= amespace ... using ... functions` stuff.

=E2=80=94 Rob
--e145c706c1ee40ddaa73c85d49cc4134--