Both sides previous revisionPrevious revisionNext revision | Previous revision |
rfc:deque_straw_poll [2022/01/09 19:07] – tandre | rfc:deque_straw_poll [2022/01/26 14:43] (current) – tandre |
---|
====== Straw poll: Naming pattern to use for Deque ====== | ====== Straw poll: Naming pattern to use for Deque ====== |
* Version: 0.1 | * Version: 0.3 |
* Date: 2022-01-05 | * Date: 2022-01-05 |
* Author: Tyson Andre, tandre@php.net | * Author: Tyson Andre, tandre@php.net |
* Status: Under Discussion | * Status: Closed |
* First Published at: http://wiki.php.net/rfc/deque_straw_poll | * First Published at: http://wiki.php.net/rfc/deque_straw_poll |
| |
but offers guidance in choosing namespace names and allows for using namespaces in new categories of functionality. | but offers guidance in choosing namespace names and allows for using namespaces in new categories of functionality. |
| |
The planned options are: | The options in this straw poll are: |
| |
* ''\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. | * ''\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. |
| |
| |
* ''\Collections\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) | * ''\Collections\Deque'' - seems like a reasonable choice of name for collections (Deque, and possible future additions such as Vector, Set, Map, Sorted Sets/Maps, etc. https://wiki.php.net/rfc/namespaces_in_bundled_extensions also allows using sub-namespaces and that may be used for things that aren't strictly collections, e.g. ''Collections\Builder\SomethingBuilder'' or functions operating on collections. |
| |
* ''\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) | * ''\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 (accessing the offset in the middle of a linked list requires traversing half the linked list, for example), 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) |
| |
While there is considerable division in whether or not members of internals want to adopt namespaces, | While there is considerable division in whether or not members of internals want to adopt namespaces, |
Those would differ from existing classes in the spl in several ways: | Those would differ from existing classes in the spl in several ways: |
| |
* Be final classes and avoid unpredictable behaviors. Extensibility has been a cause of performance issues and unexpected bugs historically, and makes code harder to reason about. | * Be final classes (or have final methods when extensibility is needed for core functionality) and avoid unpredictable behaviors. Extensibility has been a cause of performance issues and unexpected bugs historically, and makes code harder to reason about. \\ For example, [[rfc:deque#benchmarks|Deque would be memory and time efficient compared to SplDoublyLinkedList]] |
* Forbid dynamic properties. | * Forbid dynamic properties. |
* [[rfc|deque#benchmarks|Deque would be memory and time efficient compared to SplDoublyLinkedList]] | |
| |
===== Discussion ===== | ===== Discussion ===== |
<blockquote> | <blockquote> |
Given that I've suggested the most common options for these across | Given that I've suggested the most common options for these across |
many languages, it (''Collections\\') shouldn't be very controversial. The worst bit | many languages, it (''Collections\'') shouldn't be very controversial. The worst bit |
seems like picking the namespace "Collections" as this will break at | seems like picking the namespace "Collections" as this will break at |
least one package: https://github.com/danielgsims/php-collections. We | least one package: https://github.com/danielgsims/php-collections. We |
a good alternative here to "Collections", as we haven't agreed on very | a good alternative here to "Collections", as we haven't agreed on very |
much on past namespace proposals. | much on past namespace proposals. |
<blockquote> | </blockquote> |
| |
| (note that https://github.com/danielgsims/php-collections does not declare ''Collections\Deque'' anywhere: https://github.com/danielgsims/php-collections/tree/2.X/src) |
| |
=== Why plural? === | === Why plural? === |
| |
===== Vote ===== | ===== Vote ===== |
| |
| Voting started on 2022-01-12 and ended on 2022-01-26. |
| |
This vote will influence the name choice for the [[rfc:Deque|Deque RFC]] | This vote will influence the name choice for the [[rfc:Deque|Deque RFC]] |
- https://externals.io/message/116112 "(Planned) Straw poll: Naming pattern for ''*Deque''" | - https://externals.io/message/116112 "(Planned) Straw poll: Naming pattern for ''*Deque''" |
| |
| the plural 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) |
| |
| ===== Changelog ===== |
| |
| 0.2: Fix description of Collections\Deque naming choice in the introduction. |
| 0.3: Change introduction sections |