PHP RFC: Straw poll: Namespace to use for CachedIterable and iterable functionality
- Version: 0.2.1
- Date: 2021-06-01
- Author: Tyson Andre, tandre@php.net
- Status: Closed
- First Published at: https://wiki.php.net/rfc/cachediterable_straw_poll
Introduction
CachedIterable and successors to the any() and all() on iterables proposed adding additional iterable functionality to php. E.g. CachedIterable eagerly evaluates any iterable and contains an immutable copy of the keys and values of the iterable it was constructed from.
After that was created, https://wiki.php.net/rfc/namespaces_in_bundled_extensions passed.
However, as there have not been any RFCs started that propose adding functionality using namespaces other than the global namespace in existing extensions yet, I'm uncertain as to how voters will interpret the “namespaces in bundled extensions” RFC at voting time.
In particular, https://wiki.php.net/rfc/namespaces_in_bundled_extensions#core_standard_spl and https://wiki.php.net/rfc/namespaces_in_bundled_extensions#existing_non-namespaces_symbols_and_consistency can be interpreted in different ways - the RFC recommends the usage of namespaces for functionality in core, but permits functionality to use the global namespace if it would be consistent with similar non-namespaced functionality already in core/standard/spl.
In addition to that, because that RFC says “may” and “should” instead of “must”, it can be interpreted differently by different people. (I am assuming those words meant something similar to https://datatracker.ietf.org/doc/html/rfc2119 but that was not specified in the namespaces in bundled extensions RFC)
Proposal
In this straw poll, gather feedback for the functionality from CachedIterable and successors to the any() and all() on iterables RFC: any()/all()/none()/find()/reduce()
Proposed Voting Choices
Voting on this straw poll starts on June 5, 2021 and ends on June 12, 2021.
Note that due to a limitation of the wiki software, forms must be voted on separately. If you are opposed to this functionality being added to PHP in any form, please note this in addition to your preferred namespacing choice, given that https://wiki.php.net/rfc/namespaces_in_bundled_extensions has passed.
Namespace choices
https://wiki.php.net/rfc/namespaces_in_bundled_extensions strongly discourages some of the previously considered namespace options with too few or too many namespace parts.
Extensions should not use a vendor namespace.
...
Namespace names should follow CamelCase.
...
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.
Preferred namespacing choice for CachedIterable
(No namespace alternatives were suggested between announcing the straw poll and opening the straw poll in https://externals.io/message/114687#114687)
Preferred namespacing choice for successors to the any() and all() on iterables RFC: any()/all()/none()/find()/reduce()
Functionality of interest in the successor to the any() and all() on iterables RFC:
Implementation of any()/all()/none()/find()/reduce()
(functionality such as reversed(), flip(iterable): CachedIterable, etc. (which would require CachedIterable) is left out of this question)
(in this proposal, find() and reduce() act only on values of iterables, similar to how array_reduce works. Passing too many arguments is currently an error for internal functions and it is possible that it would be deprecated for user-defined functions in the future.)
(“Still too small in scope” means you would probably vote against the implementation as-is for that reason)
EDIT: The redundant option “Opposed to adding this functionality to php” was added to the vote on global functions after the start of the vote to make it easier to vote on at least one option. See “Preferred namespacing choice” for other voters opposed to the functionality.
Preferred namespace case to use for iterable/Iterable
I didn't notice this earlier, but the Namespaces in Bundled Extensions RFC recommended (but didn't mandate) that “Namespace names should follow CamelCase.” - so I'm not sure if iterable\ or Iterable\ makes the most sense to others.
This poll asks whether iterable\ or Iterable\ makes more sense - It could be argued by some that namespaces such as iterable\ should be an exception due to it also being used as a soft reserved keyword that is typically lowercase.
https://externals.io/message/114687#114689
To me, a lower-case namespace like “iterable” just looks wrong, because I'm so used to namespaces, like classes, being UpperCamels.
The connection to a keyword doesn't seem convincing to me - if anything, it highlights the possible confusion from choosing a namespace name that has a different meaning elsewhere, although I admit no brilliant alternatives spring to mind.
Regards,
-- Rowan Tommins [IMSoP]
(Aside: shorter namespace names such as iter were unpopular in a previous straw poll, and iter would conflict with https://github.com/nikic/iter)
References
- https://externals.io/message/114687 “Namespaces in bundled extensions” and iterable additions to the standard library
Changelog
0.2.1: Add “Opposed to adding this functionality to php” to the vote on which global functions to make voting on at least one option easier and note that it was also asked in the previous poll