On Wed, Jan 6, 2021 at 3:40 PM Levi Morrison <levi.morri...@datadoghq.com>
wrote:

> On Wed, Jan 6, 2021 at 1:55 AM Nikita Popov <nikita....@gmail.com> wrote:
> >
> > On Wed, Jan 6, 2021 at 2:28 AM tyson andre <tysonandre...@hotmail.com>
> > wrote:
> >
> > > Hi internals,
> > >
> > > > I've created a straw poll for the naming pattern to use for `*any()`
> and
> > > `*all()` on iterables.
> > > > https://wiki.php.net/rfc/any_all_on_iterable_straw_poll
> > > >
> > > > Background: The RFC https://wiki.php.net/rfc/any_all_on_iterable
> > > proposes adding only two functions,
> > > > but more functionality acting on iterables (array|Traversable) may be
> > > added in the future,
> > > > making it important to get feedback what people feel the best choice
> of
> > > naming pattern would be
> > > > to avoid inconsistency or name changes later on.
> > > > (Many alternatives were suggested in the initial RFC announcement -
> > > https://externals.io/message/111756)
> > >
> > > I've received more feedback than I expected from voters that were
> strongly
> > > or moderately
> > > in favor of putting new categories of functionality in namespaces.
> > >
> > > I've started a different straw poll and plan to start voting on that on
> > > the 8th (this will be the last straw poll for iterable function naming
> for
> > > this RFC)
> > > https://wiki.php.net/rfc/any_all_on_iterable_straw_poll_namespace
> > >
> > > 1. I plan to propose additional internal functions for working with
> > > iterables if this succeeds,
> > >    and would want to be sure this is the best name choice instead of
> just
> > > an acceptable name choice going forwards.
> > > 2. Additionally, this has been an opportunity for measuring overall
> > > interest in adopting namespaces for brand new categories of
> functionality.
> > >    It can be argued that this is a new category of functionality
> because
> > > existing methods work on Traversables (iterator_*) or arrays
> (array_*), but
> > > generally not both.
> > >   (classes such as https://www.php.net/manual/en/class.ffi-cdata.php
> have
> > > adopted namespaces,
> > >   but no global functions in php-src that I'm aware of have adopted
> > > namespaces yet)
> > >
> >
> > I'm happy to have these functions namespaced, but I'm not sure the
> > suggestion to namespace them under Spl makes sense. This functionality
> has
> > fairly little to do with the SPL as it is now and to be honest, by now
> > there is quite a bit of ... stigma associated with functionality that
> > resides in SPL.
> >
> > I would suggest using iterable\any and iterable\all as the names if we
> want
> > to go down this route. iterable_any and iterable_all were the by far most
> > popular choices on the previous poll, and these are just the namespaced
> > variants thereof.
> >
> > Regards,
> > Nikita
>
> On the contrary, I'm happy to accept it into the SPL. I don't want the
> SPL to be a dumping ground for everything, but I specifically
> requested it to be an option for this vote.
>

Using *just* the SPL namespace (that is, SPL\any) makes the SPL namespace a
dumping ground for everything, as you said. Once you introduce an
additional meaningful namespace in the form of SPL\iterable\any, you are
better off either dropping the SPL part and arriving at iterable\any, or
replacing SPL with something more sensible and arriving at PHP\iterable\any.

TBH I think Tyson's original approach of not including namespaces as a
possibility was the right one. We clearly still don't have any consensus on
how to structure namespaces in PHP extensions and it doesn't seem like a
question that should be resolved as a footnote of another RFC. There have
been multiple RFCs one the topic, and none of them reached anything even
approaching a consensus.

Regards,
Nikita

Reply via email to