> > 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. 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. 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. > 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. Regards, Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
