This is an old revision of the document!
PHP RFC: Straw poll: Namespace to use for CachedIterable and iterable functionality
- Version: 0.1
- Date: 2021-06-01
- Author: Tyson Andre, email@example.com
- Status: Under Discussion
- First Published at: https://wiki.php.net/rfc/cachediterable_straw_poll
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 this says “may” and “should” instead of “must”, there
Create a straw poll for the functionality from CachedIterable and successors to the any() and all() on iterables RFC: any()/all()/none()/find()/reduce()
Proposed Voting Choices
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.
https://wiki.php.net/rfc/namespaces_in_bundled_extensions strongly discourages some of the previously considered options
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
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: any()/all()/none()/find()/reduce()
(functionality such as reversed(), flip(iterable): CachedIterable, etc. that would require CachedIterable is left out of this question)
(in this proposal, find() and reduce() act only on values of iterables. 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.)