Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108250
MIME-Version: 1.0
References: <DM5PR07MB3067B7578E3F04C5A20A221AF9210@DM5PR07MB3067.namprd07.prod.outlook.com>
 <CY4PR07MB30633FFAAF6E9CC45B3ECB43F9340@CY4PR07MB3063.namprd07.prod.outlook.com>
 <CAF+90c9svofd0rJV9ooDUb+rgsgE4+cbaahUnLzYqrksY+d=WA@mail.gmail.com>
 <DM5PR07MB3067239059A936661E1100B5F9340@DM5PR07MB3067.namprd07.prod.outlook.com>
 <DM5PR07MB3067A4F37F4D8E6738582859F9300@DM5PR07MB3067.namprd07.prod.outlook.com>
 <b8e7ced4-9cec-4bde-a009-622c477a0e58@DB3EUR04FT030.eop-eur04.prod.protection.outlook.com>
 <DM5PR07MB306711A0E8F1CADB23C17CB5F9300@DM5PR07MB3067.namprd07.prod.outlook.com>
 <CAF+90c-Rmmh3+iYqFmn1E+W5-S1qT4BpPhN9wgroz=9ZudeWpg@mail.gmail.com>
 <CAOWwgpkmawRgSJ2J8ZMoh_0MBskOgwJu-=HGJ42=6EQt+vz0Gw@mail.gmail.com> <DM5PR07MB30671C0F3103E927A1532B6CF90E0@DM5PR07MB3067.namprd07.prod.outlook.com>
In-Reply-To: <DM5PR07MB30671C0F3103E927A1532B6CF90E0@DM5PR07MB3067.namprd07.prod.outlook.com>
Date: Sun, 26 Jan 2020 11:08:56 +0100
Message-ID: <CAF+90c8uCL85dVbLgapV2gOypFNBqocqvYWDB=JHKEmrq2JCwA@mail.gmail.com>
To: tyson andre <tysonandre775@hotmail.com>
Cc: Nicolas Grekas <nicolas.grekas+php@gmail.com>, Mark Randall <marandall@php.net>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b8b245059d082e87"
Subject: Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000b8b245059d082e87
Content-Type: text/plain; charset="UTF-8"

On Fri, Jan 24, 2020 at 6:58 PM tyson andre <tysonandre775@hotmail.com>
wrote:

> > I like the idea of using a meaningful value here, but think that this
> > should be using a string, i.e.
> declare(function_and_const_lookup='global')
> > rather than declare(function_and_const_lookup=global). Currently
> declare()
> > syntax uses a normal constant expression on the right hand side of the =,
> > and I don't see a strong reason why we should deviate from that for this
> > feature. An existing declare using a string is declare(encoding='UTF-8').
>
> Whether it's quoted is a low priority to me - I went with the unquoted
> implementation
> because it might be something repeated in every file of a project,
> and it'd be slightly more convenient to avoid quotes and use keywords if
> there were
> many more settings with different values (=on, =off, =warning, etc) in the
> future.
> A difference is that it makes sense to quote encodings such as UTF-8
> because of the '-',
> but not as much to quote keywords without special characters.
>

Saving two characters per file doesn't seem like a great motivation to add
additional special cases to core language syntax. Right now, declare just
types "identifier = expr", while with this change it's going to be
"identifier = (expr | a | few | extra | keywords)".

> > One option that I haven't seem much discussion on is the opposite:
Always only look in the global namespace. Any unimported unqualified usages
will be treated as fully qualified names.
> > This would match the proposed semantics for functions/consts and change
the resolution rules for classes.
> > I think this would have relatively little impact on how code is
written, as classes already tend to make extensive use of cross-namespace
references and the import is usually IDE managed.
>
> It's fairly common for NS\SubNS\ClassName to mention other classes from
NS\SubNS\OtherClassName right now,
> (more commonly than use Exception, use Throwable, etc in some cases),

Out of interest, I checked how the symbol reference distribution in
open-source projects look like. These numbers are for unique class name
references inside namespaces:

Global: int(88398)
Same namespace: int(83790)
Other namespace: int(315455)

So, most references are to classes outside the current namespace. The
number of references to global classes and classes in the same namespace is
actually pretty similar, there are 5% more global references.

From that perspective, changing the name resolution rules to always look
for the global symbol if unimported would actually slightly reduce the
number of necessary "use" statements.

> and changing that default would require changing a lot of third party
code.
> A separate option such as `declare(lookup_classes=global)` would allow
migrating to that,
> but would confuse developers switching between codebases using different
settings of lookup_classes,
> and introduce similar confusion about the rare case of multiple classes
in one file.

If we were to make such a change (hypothetically), the way I would view it
is "use new name resolution rules" or not, rather than a collection of
fine-grained options. Notably Rust made a major change to how symbols are
resolved in the 2018 edition, so such things aren't inconceivable,
especially with the right tooling.

Nikita

--000000000000b8b245059d082e87--