On Wed, Apr 14, 2021 at 4:18 PM Nikita Popov <nikita....@gmail.com> wrote:
> On Mon, Apr 5, 2021 at 8:05 PM tyson andre <tysonandre...@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
