"Namespaces in bundled extensions" and iterable additions to thestandard library

  114687
June 2, 2021 01:30 tysonandre775@hotmail.com (tyson andre)
Hi internals,

Recently, there have been 3 proposals to add functionality related to iterables/iterators to the standard library where voting was postponed for reasons related to namespacing policy:

1. https://wiki.php.net/rfc/any_all_on_iterable - where major objections were not having enough functionality and the choice of namespace.

   If this did go with a namespace, I believe iterable\any(), iterable\all(), etc. would be reasonable.

   iterable\X was the most popular choice among choices with a single namespace part - https://wiki.php.net/rfc/any_all_on_iterable_straw_poll_namespace
2. https://wiki.php.net/rfc/cachediterable - My preference would be iterable\CachedIterable.

   With this being one of the first proposed namespaced additions to PHP, I felt obligated to gather feedback on alternative namespace choices.
3. https://externals.io/message/113061 and https://github.com/php/php-src/pull/6535 by Levi Morrison - I'm uncertain of the status of this, e.g. what name the author had planned to go with "Namespaces in bundled extensions" namespace RFC passed weeks ago.

https://wiki.php.net/rfc/namespaces_in_bundled_extensions passed 37-1, but as nobody has created any RFCs using namespaces that I know of,
I'm uncertain if voters would prefer namespaces over the global namespace in practice for extensions that already have functions, and even if namespaces are preferred, there may be multiple candidates.

I plan to start a straw poll (https://wiki.php.net/rfc/cachediterable_straw_poll) in a few days to gather information on

1. How voters interpret the https://wiki.php.net/rfc/namespaces_in_bundled_extensions RFC for existing namespaces,
    as it makes recommendations but also permits the global namespace for new functionality consistent with existing functionality - the way I expect voters to interpret it may be different from how it is interpreted in practice.

   iterable_all() seemed to have been preferred over iterable\all in the previous straw poll.
   However, I would expect https://wiki.php.net/rfc/namespaces_in_bundled_extensions to shift that preference towards namespaces but there have been no votes on an RFC using namespaces yet.

   Additionally, I didn't notice this earlier, but the 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.
2. To see if there's interest in that functionality before spending too much time on it. E.g. for CachedIterable, https://externals.io/message/113136 had little feedback
    but would enable implementing a standard library for iterables thtat was much wider in scope (e.g. iterable\flip(), iterable\reversed(), iterable\take(), etc)

(Sorry - It is difficult to tell if feedback from a small number people on a mailing list is representative of the majority of voters and there have been no RFCs for me to look at as a precedent).

Questions I had:
- Did anyone interested in adding CachedIterable have a different idea for namespace choices that should be included in the poll?
- Did anyone have feedback on whether iterable\ or Iterable\ makes more sense - Personally, iterable\ seems like it should be an exception due to it also being used as a soft reserved keyword that is typically lowercase.
- Any feedback on CachedIterable's functionality?
- Any other feedback?

Regards,
Tyson
  114689
June 2, 2021 07:57 rowan.collins@gmail.com (Rowan Tommins)
On 02/06/2021 02:30, tyson andre wrote:
> - Did anyone have feedback on whether iterable\ or Iterable\ makes more sense - Personally, iterable\ seems like it 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. Regards, -- Rowan Tommins [IMSoP]