On Wed, Apr 14, 2021, at 9:52 AM, Nikita Popov wrote:
> >> > All symbols defined in the extension should be part of the top-level
> >> namespace or a sub-namespace.
> >>
> >> This should be clarified - do you mean **the extension's** top-level
> >> namespace (e.g. OpenSSL) instead of the global namespace? I assume the
> >> former.
> >>
> >
> > Indeed, that's what I meant. I've added the extra word.
> >
> > Regards,
> > Nikita
> >
>
> I've now added an explicit section regarding namespace collisions to the
> RFC, and tweaked some of the examples (String\contains, Array\contains).
>
> If there's no further feedback I'll open voting soon.
>
> Regards,
> Nikita
Thanks, Nikita.
Only one remaining question/comment/request from my end: In the "Migration of existing
symbols" section, can you clarify explicitly that this RFC does not preclude such migration
proposals in the future? The reading of the previous section could easily be taken in the future to
mean "and existing code is stuck where it is forever", even if that's not the intent.
Eg, it's fine that the RFC does not propose mass-migrating all str_* functions to Str\*, but if
someone in the future proposes doing that migration (with shims/aliases), that should be able to
stand on its own merits. I want to preempt anyone trying to respond in such a discussion "the
original RFC said they wouldn't move, so you can't do this migration RFC now,"
because I'm sure someone will try to use that angle in the future should such a proposal
appear. :-)
Thanks again.
--Larry Garfield