Hi Pierre, > > While there is considerable division in whether or not members of internals > > want to adopt namespaces, > > I hope that the final outcome of the poll will be accepted by members of > > internals > > as what the representative of the majority of the members of internals > > (from diverse backgrounds such as contributors/leaders of userland > > applications/frameworks/composer libraries written in PHP, > > documentation contributors, PECL authors, php-src maintainers, etc. (all of > > which I expect are also end users of php)) > > want to use as a naming choice in future datastructure additions to PHP. > > (and I hope there is a clear majority) > > > > ----- > > > > Are there any other suggestions to consider for namespaces to add to the > > straw poll? > > > > Several suggestions that have been brought up in the past are forbidden by > > the accepted policy RFC > > (https://wiki.php.net/rfc/namespaces_in_bundled_extensions > PHP: rfc:namespaces_in_bundled_extensions > Classes and functions provided by bundled PHP extensions are currently all > located in the global namespace (with one exception). There is a strong > sentiment that future additions to PHP's standard library should make use of > namespaces, to the point that otherwise unrelated proposals increasingly > degenerate into namespace-related discussions. > wiki.php.net > ) > > and can't be used in an RFC. > > > > - `Spl\`, `Core\`, and `Standard\` are forbidden: "Because these extensions > > combine a lot of unrelated or only tangentially related functionality, > > symbols should not be namespaced under the `Core`, `Standard` or `Spl` > > namespaces. > > Instead, these extensions should be considered as a collection of > > different components, and should be namespaced according to these." > > - More than one namespace component (`A\B\`) is forbidden > > - Namespace names should follow CamelCase. > Besides the namespace thing (collection is fine imho). What is the > reason to have it final?
Do you want singular Collection included as an option in addition to plural in https://wiki.php.net/rfc/deque_straw_poll ? The reasons it was a `final` class in this RFC was described in https://wiki.php.net/rfc/deque#final_class. It's easier to change a `final` class to a non-final class with final methods if needed later on. (final methods so that array access, etc. continues to be fast, easy to reason about, bug/crash-free, etc) > For collection in general, would it make sense to have a common > interface representing the minimum expected API? If possible, then > algorithm specific on top? a bit like we have with the traversable > interface and related. php-ds does this as https://www.php.net/manual/en/class.ds-collection.php and I've been considering it Still, - With union types and intersection types, it's still useful but isn't as compelling. - There's the choice of namespacing to consider for the new namespace (`Collection` vs `Collections\Collection`). - It didn't seem as useful until there were more datastructures to choose from and situations where more than one would be chosen. - It couldn't be used until support for php <= 8.1 was dropped by applications/libraries, so it'd take a while to be adopted. Thanks, Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
