Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108228
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>
In-Reply-To: <DM5PR07MB306711A0E8F1CADB23C17CB5F9300@DM5PR07MB3067.namprd07.prod.outlook.com>
Date: Fri, 24 Jan 2020 17:00:06 +0100
Message-ID: <CAF+90c-Rmmh3+iYqFmn1E+W5-S1qT4BpPhN9wgroz=9ZudeWpg@mail.gmail.com>
To: tyson andre <tysonandre775@hotmail.com>
Cc: Mark Randall <marandall@php.net>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e432e7059ce4da59"
Subject: Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000e432e7059ce4da59
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Jan 18, 2020 at 11:53 PM tyson andre <tysonandre775@hotmail.com>
wrote:

> > I'd much rather have something like:
> >
> > declare(ambiguous_element_lookup=3D0)
> >
> > declare(ambiguous_element_lookup=3Doff)
>
> Aside: declare(unambiguous_element_lookup=3D1) is probably a better choic=
e
> than my first choice of (disable_ambiguous_element_lookup=3D1), but proba=
bly
> not the best choice.
>
> > I find that the =E2=80=9Cdisable_ambiguous_element_lookup=E2=80=9D dire=
ctive name is,
> well, ambiguous.
> > Does it mean that it will look up only in the current namespace, or onl=
y
> in the global namespace? I can=E2=80=99t guess.
> >
> > Maybe a three-value directive:
> >
> >    declare(function_and_const_lookup=3Dglobal);
> >    declare(function_and_const_lookup=3Dnamespace);
> >    declare(function_and_const_lookup=3Dfallback); // the default
>
> That's my favorite setting name overall so far - it ends up being as long
> as disable_ambiguous_element_lookup and more self-explanatory.
> I don't plan to include namespace-only in the RFC - future RFCs could
> propose additional values independently.
>
> Probably just `=3D global` and `=3D default`, because the default might
> eventually change (from the fallback),
> and =3D fallback could be added if the old fallback was desirable enough.
> - `=3D default` would only be useful to set resolution back to the defaul=
t
>   with future language changes such as
> https://wiki.php.net/rfc/namespace_scoped_declares#implementation_conside=
rations
>

It looks like the implementation has been updated to the style proposed
here, while the RFC still uses disable_ambiguous_element_lookup.

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=3D'global'=
)
rather than declare(function_and_const_lookup=3Dglobal). Currently declare(=
)
syntax uses a normal constant expression on the right hand side of the =3D,
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=3D'UTF-8').

The RFC says:

function sprintf($msg, ...$args) {
    // this and remaining statements still refer to \sprintf, not
MyNS\sprintf
    return sprintf("Prefix $msg", ...$args);
}

This looks a bit peculiar... We could also say that declaring a symbol also
automatically brings it into scope. I'm not really sure which is better.

As a general note on the overall proposal: I think this is a very pragmatic
proposal. It addresses a real issue, and it addresses it in the most
straightforward way. You can just drop the declare in your code, and it
will keep working exactly as it did before, just faster. Assuming you
weren't doing anything stupid, of course.

The big downside is that this makes class and function symbol resolution
complete opposites. Classes only look in the current namespace. Functions
only look in the global namespace. This reflects the way they are most
commonly used, but is not a great place to end up from a language design
perspective.

There are two alternatives that keep class and function symbol resolution
the same: One is to always only look in the namespace. This has been
suggested a few times in the past, including in this thread, and the RFC
https://wiki.php.net/rfc/fallback-to-root-scope-deprecation. I think this
is a fairly unpopular option, because using fully qualified names for
functions tends to be quite ugly (more so than for classes, due to the
positions they're used in), or requires a large number of imports, as even
a small piece of code can easily use a dozen different string/array
functions.

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.

Regards,
Nikita

--000000000000e432e7059ce4da59--