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