Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108285
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>
 <CAOWwgp=WB7sCKTovDEt6shOFZvyHWKxgCT0mdcvYHqLitCQmfw@mail.gmail.com> <DM5PR07MB306745D45674C7C7380C358BF90B0@DM5PR07MB3067.namprd07.prod.outlook.com>
In-Reply-To: <DM5PR07MB306745D45674C7C7380C358BF90B0@DM5PR07MB3067.namprd07.prod.outlook.com>
Date: Tue, 28 Jan 2020 10:50:56 +0100
Message-ID: <CAOWwgpkrDt3fSXEus0mPcXQdOYvKJszAsZGEiGzPk5fDyf5ySQ@mail.gmail.com>
To: tyson andre <tysonandre775@hotmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b9f411059d302981"
Subject: Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000b9f411059d302981
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le lun. 27 janv. 2020 =C3=A0 16:10, tyson andre <tysonandre775@hotmail.com>=
 a
=C3=A9crit :

> > can we please discuss this alternative? In another reply, you link to
> https://wiki.php.net/rfc/use_global_elements#deprecate_the_fallback_to_th=
e_root_namespace_instead
> >
> > But this new proposal derived from Nikita's idea is different as it
> doesn't need to deprecate anything.
>
> I've added
> https://wiki.php.net/rfc/use_global_elements#add_setting_to_make_all_name=
_lookups_global_instead_eg_declare_global_lookup_1
> to the discussion notes for the RFC.
>

Thanks. It's a bit strange to read the objections to the proposal in the
RFC. That makes it feel like "we" agreed on them - while it's "only" the
author's opinion. From this part in the RFC:

> and changing that default would require changing a lot of third party
code.

not unless it's opt-in, which it is.

> A separate option such as `declare(lookup_classes=3Dglobal)` would allow
migrating to that,

better have lesser declare() directives IMHO.

> 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.

Not sure how this would be different than any other declare directive -
either the currently proposed one or even strict_mode.


https://wiki.php.net/rfc/use_global_elements is opt-in, and also doesn't
> need to deprecate anything. The link you mention
> is a different proposal that has deprecations for constants and functions=
.
>
> > I'm not comfortable with having a 3-ways declare directive. Who will
> pick which of the 3 and for what reason?
> > That's going to be a mess to review. If we're looking for a forward
> path, there should be only one opt-in way: a boolean flag.
>
> I'm not sure what you mean by 3 ways. It's at most two, and a setting for
> global name lookup might become mutually exclusive (forbid using both
> setting names)
>

I meant 'default', 'fallback', 'global', and declare()-omitted. Rowan's
latest message is a better ground to discuss this so let's continue there -
I share his concerns.

BTW, should we use the word "root" instead of "global"? "global" might have
a bad connotation, and "root" is the word used in the description of the
current behavior of PHP:

declare(function_and_const_lookup=3D'root')


> You mention this should be another RFC. But process-wise, I think it
> would be better to vote only once on a specific topic, vs having several
> iterations that undo previous RFCs before having a stable consensus.
>
> The issue with that is that there's no good way to set up a vote or poll
> for that in the RFC structure.
>

For sure, I'm not suggesting to add a sub-vote. I think we should be able
to discuss the best proposal we can imagine all together and put it under a
yes/no vote.

Reusing the "root" word, I think we might want to upgrade the current
proposal to:

declare(root_lookup=3D1)


I'd see global_lookup=3D1 and function_and_const_lookup=3D'global' as being
> significantly different in who would vote on them.
> The former requires a lot more refactoring and code changes to handle
> changes to class name resolution,
> compared to the code changes of just changing function and constant
> resolution.
>

No proposal requires any refactoring if things are opt-in: existing
codebases will continue to work as-is. New ones might start with the new
declare directive. Existing codebases could also adopt the directive once
the tooling is ready. Eg. php-cs-fixer has all the required infrastructure
to automate this transition *for authors that want to do it*.



> And because changing resolution of class names has those drawbacks, I
> don't plan to change direction within this RFC.
>

I don't see these as drawbacks, especially when the target is cleaning up
the rules of the engine for a better future :)

Can you please consider it? While this reply might feel like I'm "just"
criticizing your work, it's not: I'm very thankful for what you're doing
here and I think you are doing a great job. I'm "just" trying to help shape
the best proposal for the best future of PHP, although very modestly :)

Doesn't anyone else share my points?

Nicolas

--000000000000b9f411059d302981--