Hi internals,
> Because the naming choice for new datastructures is a question that has been asked many times,
> I plan to create another straw poll (Single transferrable vote) on wiki.php.net to gather feedback on the naming pattern to use for future additions of datastructures to the SPL,
> with the arguments for and against the naming pattern.
>
> https://wiki.php.net/rfc/namespaces_in_bundled_extensions recently passed.
> It permits using the same namespace that is already used in an extension,
> but offers guidance in choosing namespace names and allows for using namespaces in new categories of functionality.
>
> The planned options are:
>
> 1. `\Deque`, the name currently used in the RFC/implementation. See https://wiki.php.net/rfc/deque#global_namespace
>
> This was my preference because it was short, making it easy to remember and convenient to use.
> 2. `\SplDeque`, similar to datastructures added to the `Spl` in PHP 5.3.
>
> (I don't prefer that name because `SplDoublyLinkedList`, `SplStack`, and `SplQueue` are subclasses of a doubly linked list with poor performance,
> and this name would easily get confused with them. Also, historically, none of the functionality with that naming pattern has been final.
> However, good documentation (e.g. suggesting `*Deque` instead where possible in the manual) would make that less of an issue.)
>
> See https://wiki.php.net/rfc/deque#lack_of_name_prefix (and arguments for https://externals.io/message/116100#116111)
> 3. `\Collection\Deque` - the singular form is proposed because this might grow long-term to contain not just collections,
> but also functionality related to collections in the future(e.g. helper classes for building classes
> (e.g. `ImmutableSequenceBuilder` for building an `ImmutableSequence`), global functions, traits/interfaces,
> collections of static methods, etc.
> (especially since https://wiki.php.net/rfc/namespaces_in_bundled_extensions prevents more than one level of namespaces)
>
> Additionally, all existing extension names in php-src are singular, not plural. https://github.com/php/php-src/tree/master/ext
> (Except for `sockets`, but that defines `socket_*` and `class Socket` and I'd assume it would be named `Socket\` anyway, the rfc didn't say exactly match?)
>
> So the namespace's contents might not just be `Collections`, but rather all functionality related to a `Collection`)
> Also, the examples in the "namespaces in bundled extension" RFC were all singular
>
> > For example, the `array_is_list()` function added in PHP 8.1 should indeed be called `array_is_list()`
> > and should not be introduced as `Array\is_list()` or similar.
> > Unless and until existing `array_*()` functions are aliased under an Array\* namespace,
> > new additions should continue to be of the form `array_*()` to maintain horizontal consistency.
>
> **NOTE: This later was changed to `Collections\\`, I misread the namespaces in bundled extensions RFC, and sub-namespaces are allowed**
>
> See https://wiki.php.net/rfc/deque#global_namespace (and https://externals.io/message/116100#116111)
>
> Also, straw polls for other categories of functionality (https://wiki.php.net/rfc/cachediterable_straw_poll#namespace_choices)
> had shown interest of around half of voters in adopting namespaces,
> there was disagreement about the best namespace to use (e.g. none that were preferred to the global namespace),
> making me hesitant to propose namespaces in any RFC. For an ordinary collection datastructure, the situation may be different.
>
> 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)
> 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.
The straw poll https://wiki.php.net/rfc/deque_straw_poll has been written, and voting on the straw poll will be started on Wednesday, January 12th.
The naming option was also changed to `Collections\` on reflection, as proposed in https://externals.io/message/116100#116119
Are there any arguments for/against the naming choices that you'd like to see in the straw poll?
Thanks,
Tyson
