Re: [PHP-DEV] (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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] (Planned) Straw poll: Naming pattern for `*Deque`
Hi Tyson, On Tue, Sep 21, 2021 at 9:19 AM tyson andre wrote: > > 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. Besides the namespace thing (collection is fine imho). What is the reason to have it final? 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. best, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] (Planned) Straw poll: Naming pattern for `*Deque`
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. 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. Thanks, Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
