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, firstname.lastname@example.org
- 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
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
Functionality of interest in the successor to the any() and all() on iterables RFC:
(functionality such as
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.)
Preferred namespace to use for 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\ makes the most sense to others.
This poll asks whether
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.
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.
-- Rowan Tommins [IMSoP]
https://externals.io/message/114687 “Namespaces in bundled extensions” and iterable additions to the standard library