Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114056
MIME-Version: 1.0
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>
In-Reply-To: <CAF+90c9eV0mQWjueLgejP_ezft=J7XHfebcdqWbH8xpS-R8NGg@mail.gmail.com>
Date: Wed, 14 Apr 2021 16:52:40 +0200
Message-ID: <CAF+90c-zqHdATW7tM=+OTp79dztU7m3BxO3RUgtPxe8rH0aZ7w@mail.gmail.com>
To: tyson andre <tysonandre775@hotmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f89db805bfefe66c"
Subject: Re: [PHP-DEV] [RFC] Namespaced in bundled extensions
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000f89db805bfefe66c
Content-Type: text/plain; charset="UTF-8"

On Wed, Apr 14, 2021 at 4:18 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Mon, Apr 5, 2021 at 8:05 PM tyson andre <tysonandre775@hotmail.com>
> wrote:
>
>> > > The question of namespaces in the stdlib has been coming up a lot
>> recently,
>> > > so I'd like to present my own stab at resolving this question:
>> > >
>> > > https://wiki.php.net/rfc/namespaces_in_bundled_extensions
>> > >
>> > > Relative to a number of previous (declined) proposals, the main
>> difference
>> > > is that I do not propose a top-level "PHP\" vendor namespace, and
>> instead
>> > > recommend the use of "ExtName\", in line with existing practice for
>> > > extensions. I believe this addresses the primary concern with previous
>> > > proposals.
>> >
>> > Both of the namespacing RFCs have been announced for over 3 weeks and I
>> don't think I've
>> > seen any new discussion since then.
>> > Are any updates planned? When will voting on the namespacing RFC(s)
>> start?
>> > (I had some stdlib RFCs/RFC ideas I was postponing since February to
>> avoid interfering with the namespacing discussion)
>> >
>> > I'd love to have some more feedback on this RFC before opening voting.
>> There has been a lot of discussion beforehand, but only a couple responses
>> to this RFC...
>>
>> I didn't plan to suggest changing the direction of the RFC, so I didn't
>> have much to say.
>> I guess it's an improvement from a user perspective and that splitting
>> core/PECL/composer namespacing wouldn't make much sense,
>> especially with the ability to polyfill most core functionality in
>> composer packages (especially with PHP providing FFI, low level
>> socket/stream code, etc).
>>
>> For something like https://wiki.php.net/rfc/cachediterable I'd still be
>> faced with the namespacing choice among multiple options if this passed,
>> but choosing names for everything is out of the scope of this RFC.
>>
>> - `iterable\CachedIterable` would be the most likely, although it's also
>> in some ways a datastructure
>> - For SPL, e.g. for a new Map type or existing classes such as
>> SplObjectStorage,
>>   there'd still be a number of different names such as
>> `DataStructure\Map` or `Collections\Map` (DS is already used by an
>> independent PECL)
>> - "When adding new symbols to existing extensions, it is more important
>> to be consistent with existing symbols than to follow the namespacing
>> guidelines."
>>   raises the question of whether existing iterables should be aliased to
>> a namespace around the same time
>> - 5 years from now we may have a different group of active voters, so if
>> this passed with low voting turnout
>>   I'm not sure if there'd still be arguments over the choice to use/not
>> use a namespace.
>>
>
> Right. I think the two main things this RFC establishes is that a) yes, it
> *is* okay to use a namespace and b) that namespace should not have a PHP\
> prefix. That still leaves you with quite a lot of different choices, but I
> think it removes the two most contentious issues from further discussion.
>
>
>> For a future iteration of https://wiki.php.net/rfc/any_all_on_iterable
>> it'd help if there was known community consensus (i.e. the vote on
>> namespaces in bundled extensions finished)
>>
>> I didn't notice before, but I assume you'd still planned to summarize
>> feedback so far in a discussion section before opening
>> https://wiki.php.net/rfc/namespaces_in_bundled_extensions
>>
>> For
>> https://wiki.php.net/rfc/namespaces_in_bundled_extensions#core_standard_spl
>> `use Array;` and `use String;` are currently syntax errors for the
>> unexpected token "array".
>> That could be fixed in the parser by adding a special case for namespace
>> uses,
>> especially now that T_NAMESPACED_NAME now allows `string\contains` to be
>> used without a syntax error.
>>
>
> Yes, those particular examples are somewhat problematic. I believe my
> original version of https://wiki.php.net/rfc/namespaced_names_as_token
> also allowed those "use" statements, so this isn't a technical problem for
> a new PHP version that decides to use them. It would be a problem for
> polyfills though, which is why we'd probably want to go for some other
> naming here. Say Str\contains instead of String\contains. (Worth noting
> that this issue also exists with "PHP\Array" before PHP 8.0, so it's not a
> problem that presence of a vendor prefix would resolve, outside specific
> cases.)
>
>
>> One possible concern is what would happen if PHP implemented new
>> functionality that overlapped with a fairly well-known PECL/Composer
>> package.
>> E.g. if there was already a FooDB\Client in a composer/PECL package, and
>> an independent implementation was later added to php-src,
>> there'd potentially be conflicting names.
>> Being able to implement `PHP\FooDB\Client` would avoid that ambiguity
>>
>> - Then again, other programming languages such as Python have no issue
>> with that, so never mind.
>>   FooDBClient\ or Foo\ or something could probably be used.
>>
>
> Right. For an existing PECL extension it would be best to just bundle it
> instead of implementing a new one (even though that seems to be in fashion
> recently...) But for the more general question, we should try to be
> courteous and avoid collisions with important known libraries/extensions.
> There's usually enough leeway with naming. If worst comes to worst, you can
> always pull a mysql + mysqli :)
>
>
>> > 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

--000000000000f89db805bfefe66c--