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
