On Wed, Apr 14, 2021 at 5:39 PM Larry Garfield <la...@garfieldtech.com> wrote:
> 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. :-) > Yeah, I definitely didn't want to imply that such a migration can't happen in the future. I've now moved this into a "Future Scope" section ( https://wiki.php.net/rfc/namespaces_in_bundled_extensions#future_scope). Hopefully that makes it clear that a followup RFC can deal with this question. Regards, Nikita
