Re: (Planned) Straw poll: Naming pattern for `*Deque`

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