Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125131 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 9AAB11A00BD for ; Fri, 23 Aug 2024 12:23:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1724415926; bh=sUlfUFjje7yYBZNYWU15I1MzVOzU8oeJuilBwpWruEc=; h=Date:From:To:In-Reply-To:References:Subject:From; b=NXO00FpicpHlYJp8x/KG5JOsOP3h6pa5P4AxmxXdCv5QF0U1C+iOGhm0FI7eI+356 2PFWiq53ca8BKQhiyj+hHSQbuPaq2BtO0lkpP1RMmxy6B1TvR0Mwrhc4prH6YeId1c NCRdQpCnpezq1KqYE2LwD/CKF6QzBIar2GT1EZDUkMSWTjhFkvXgEYBXaLJgYua+fm QSfLvqi8s9SkTYKFrIYiVIwSuoiTI2qDPjOOabD/aRTDq9yt+RwgF3NwjwYeZIWavu qQ6JZeAAJa3Gs5f8CcpCXBoKtMgBAUJHL9/YhLYSuNztkB7R+Z+u0wib5pdld5+ePs fauE4vYNismIA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 9C49F180392 for ; Fri, 23 Aug 2024 12:25:25 +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 fout1-smtp.messagingengine.com (fout1-smtp.messagingengine.com [103.168.172.144]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 23 Aug 2024 12:25:25 +0000 (UTC) Received: from phl-compute-03.internal (phl-compute-03.nyi.internal [10.202.2.43]) by mailfout.nyi.internal (Postfix) with ESMTP id E4261139002D for ; Fri, 23 Aug 2024 08:23:33 -0400 (EDT) Received: from phl-imap-09 ([10.202.2.99]) by phl-compute-03.internal (MEProxy); Fri, 23 Aug 2024 08:23:33 -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=1724415813; x=1724502213; bh=zEBbBqBTfs +bT66Z/ICSf8ntzo7/1yvsvFLQaXyW+/M=; b=OOdVmk9qrABKh8XTahdWqhgWcC BCBux1NpRIg8AN4wFj/84zLnrMbkajHYx6wH3/K08C5iRRr8DQD6jxF5ngaPOvuc go+JqvnnOydPX7IjVe7g8BoZPS5vliz0RxHMFAmvPI56GqXccu4JgcR59zk13Ay6 gNanAQbpn9OUc3IRf2q8mtAXaz5j0AySmSDRh+jv1M+ZDbdPsVwyPa1JzAiicwhA BAauB+eD3XWz4S8zMO93hq665DHTEOSTlV7qCPgc3w4R5AE/5w2WnNpExLrQ08+n RcjG/+tUqhQ5pj1avFK52aDnNT2BaZTf69HUJ1Vd1BhSEfRXDOYTjRNJtP1g== 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=1724415813; x=1724502213; bh=zEBbBqBTfs+bT66Z/ICSf8ntzo7/ 1yvsvFLQaXyW+/M=; b=f/Wd5q4VIjid8umxOb+qADTciOVUaJ4b3maBDT4/WtK4 d5dbhLH3/cKVck/SfcfZlzskI44vNllcrdRsLK4ZL7SNS14Y+O2Tx+F5yBC0piGy kPhKykqVymz6717F/FHeUSqcQZlYPOewSZwzol+yk7jZVzbqzndGCpK1C62lYmWz cbY92FqzCgWA9yknUFRtbW6XwIeWp712/oG4W6gDnxzq7zzmAJMOmEHp992n3U6f 1f7pzvZ91C7UjiVr3SAU199P/Nr3C7eiYZgWD3mGcpV1QLC/fnnQs6hZKeaIqhmd ymXHC7Pyqj4s6J7WcGklHsCxI27JJXJkmiFyX7UyfA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddruddvvddgheduucetufdoteggodetrfdotf 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 9A9BE780065; Fri, 23 Aug 2024 08:23:33 -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:23:11 +0200 To: internals@lists.php.net Message-ID: <992ce7eb-e84f-4edd-9dae-41de04fd484b@app.fastmail.com> In-Reply-To: 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=a428c48f15514e2099af4fcbb5ad34ac From: rob@bottled.codes ("Rob Landers") --a428c48f15514e2099af4fcbb5ad34ac Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, Aug 23, 2024, at 14:16, Rob Landers wrote: > 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 whe= re >> 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 al= l? >>=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 namespa= ce >> 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 functi= on >> *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 >=20 > I personally would find option 3 to be the best of both worlds, and yo= u don't even need the `namespace ... using ... functions` stuff. >=20 > =E2=80=94 Rob Totally sent that before finishing... My only two concerns are: 1. Calling functions in the current namespace. I don't want that syntax= to change.=20 2. Changing the order might make function autoloading impossible; forev= er. If these concerns can be ameliorated, then I don't really care much abou= t the specifics. =E2=80=94 Rob --a428c48f15514e2099af4fcbb5ad34ac Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Fri, Aug = 23, 2024, at 14:16, Rob Landers wrote:
On Fri, Aug 23, 2024, at 11:27, Nick Lockhea= rt wrote:
On Fri, 2024-08-23 at 09:16 +0100, Rowan Tommins [IMSoP] wrote:
> 
> 
> On 23 Aug= ust 2024 01:42:38 BST, Nick Lockheart <lists@ageofdream.com>
> wrote:
> > 
> > > 
= > > > BUT, if people already complain about "\" being ugly, hav= ing to
> > > write
> > > "= namespace\" is going to make them REALLY grumpy...
> &g= t; > So maybe at the same time (or, probably, in advance) we need to<= br>
> > > come
> > > up with a= nicer syntax for explicitly referencing the current
> = > > namespace.
> > 
> &g= t;    namespace foo using global functions;
>= > 
> > - or - 
> >=  
> >    namespace foo using local fu= nctions;
> > 
> > 
=
> > Tell PHP what you want at the per-file level.
> 
> 
> This doe= sn'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.&nbs= p;

Correct, so if you use the example:
<= /div>

    namespace foo using global f= unctions;

you can write:

=
    array_key_exists();

and it will be resolved as global without 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 declaration as part of the name= space
declaration just turns off namespace lookups and set= s the default
resolution for **unqualified** names.

Fully qualified names are not affected.
=


> 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
> disru= ptive to existing code.


They= are compatible, but related decisions.

I t= hink it would be easier for people to accept a new PHP version where
=
unqualified names were always global, if we also had an optio= n to make
local/namespaced the default resolution for *unq= ualified* names, on a
per-file basis, for those who need t= hat.


Thus, there are multipl= e decision points:

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

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

3. Regardless of 1 or 2, should we let develo= pers explicitly specify a
behavior for unqualified calls i= n the namespace declaration?

4. If yes to 1= , should the behavior of namespace lookups change for
user= -defined functions vs PHP built-in function names?


These aren't mutually exclusive, but they all wor= k together to create a
complete behavior.
There are several ways that the above options could be comb= ined:



### OPT= ION ONE ###

Using a regular namespace decla= ration still does an NS lookup, in the
same order, just li= ke it normally works now.

That means that c= ode that uses:

    namespace= foo;

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

Developers using the n= ew PHP version could opt-in to explicit namespace
behavior= with:

    namespace foo usi= ng global functions;

or

<= /div>
    namespace foo using local functions;

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

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



### OPTION TWO ###

= Namespace lookup is removed from a future version of PHP.
=
Code that uses the current namespace declaration: 

    namespace foo;
<= div>
will assume that all unqualified function calls are g= lobal scope.

To use a function in the local= namespace, it can be fully qualified
with:
=
    \foo\MyFunction();

<= /div>

But, developers could also write:

     namespace foo using local funct= ions;

And all unqualified function names wo= uld be resolved to local at
compile time. Global functions= could still be accessed with a `\` if
this directive was = used:

    \array_key_exists(= );



### OPTION= THREE ###

Namespace lookup is removed from= a future version of PHP.

Code that uses th= e current namespace declaration:

 &nbs= p;  namespace foo;

...will assume that= an *unqualified* function name is a global function
*IF* = it is a PHP built-in function.

Otherwise, *= unqualified* function names that are *not* PHP built-in
fu= nctions will be presumed to be local to the namespace.
With Option Three, developers can still fully-qualify their = functions:

    \foo\array_ke= y_exists();

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

Likewise, a fully-qualified:

<= div>    \MyFunction();

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

Only unqualified names are affected.
<= br>
As an additional optional feature of Option Three, develop= ers can
change this behavior with:

    namespace foo using global functions;
=

or

    n= amespace foo using local functions;


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

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


<= div>
Of course, there are many other possibilities that ca= n be mixed-and-
matched.


I personally would find option 3 to be the best = of both worlds, and you don't even need the `namespace ... using ... fun= ctions` stuff.

=E2=80= =94 Rob

Totally sent that befo= re finishing...

My only two concerns are:
  1. Calling functions in the current namespace. I don't want= that syntax to change.
  2. Changing the order might make funct= ion autoloading impossible; forever.
If these concerns= can be ameliorated, then I don't really care much about the specifics.<= /div>

=E2=80=94 Rob
--a428c48f15514e2099af4fcbb5ad34ac--