Le lun. 27 janv. 2020 à 16:10, tyson andre <tysonandre...@hotmail.com> a
écrit :

> > can we please discuss this alternative? In another reply, you link to
> https://wiki.php.net/rfc/use_global_elements#deprecate_the_fallback_to_the_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=global)` 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='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=1)


I'd see global_lookup=1 and function_and_const_lookup='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

Reply via email to