Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114057
User-Agent: Cyrus-JMAP/3.5.0-alpha0-273-g8500d2492d-fm-20210323.002-g8500d249
Mime-Version: 1.0
Message-ID: <66e4d926-0d3a-4588-b5a6-ddd863de3ecf@www.fastmail.com>
In-Reply-To: 
 <CAF+90c-zqHdATW7tM=+OTp79dztU7m3BxO3RUgtPxe8rH0aZ7w@mail.gmail.com>
References: 
 <CAF+90c-CEZycXeigN9zqsFyZGMxDWVT_YU6h_OMrvORE_qLk3A@mail.gmail.com>
 <DM6PR07MB66184EA01CF9B375E44C3D53F9689@DM6PR07MB6618.namprd07.prod.outlook.com>
 <CAF+90c_N=DsskYuT_i_C473dk+MrvsLRt3gzPM120A9yjyCZeg@mail.gmail.com>
 <DM6PR07MB66186811B63B4FBDF94AD4B3F9779@DM6PR07MB6618.namprd07.prod.outlook.com>
 <CAF+90c9eV0mQWjueLgejP_ezft=J7XHfebcdqWbH8xpS-R8NGg@mail.gmail.com>
 <CAF+90c-zqHdATW7tM=+OTp79dztU7m3BxO3RUgtPxe8rH0aZ7w@mail.gmail.com>
Date: Wed, 14 Apr 2021 10:38:55 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] Namespaced in bundled extensions
From: larry@garfieldtech.com ("Larry Garfield")

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