Re: Straw poll: Naming for `*any()` and `*all()` on iterables

Hi Levi, > I want to re-iterate my opinion on this discussion thread: anything > with a prefix is a hard-no from me. Namespaces are literally designed > for this, and I will not vote "yes" to iter_all, > iterable_all, > etc, no matter what the prefix is. Anything without a namespace is a > no from me. > > I'm flexible on many other points, but not this one. It's 2020 (almost > 2021); let's use namespaces for what they were designed for. This is a > perfect opportunity; they work on more than just arrays so using the > array_ prefix for consistency doesn't apply. I can understand the argument that somewhat of a new category of functionality making it a candidate for a new namespace, but it's common enough for me to want it in the global namespace (any of the language examples in https://wiki.php.net/rfc/any_all_on_iterable#introduction have it in an object method, or in a close equivalent to a namespace imported by default such as std::) My goal is to add two functions, not the much, much larger goal of setting a precedent for the many topics which adopting namespaces would provide (choice of prefix, choice of casing, choice of SPL\, EXT\SPL\, PHP\, PHP\iterable\, or Spl\, or iterable\, whether the extra verbosity is worth the benefit, etc.), which may be more contentious than the decision to not start using namespaces here. Both https://wiki.php.net/rfc/php-namespace-in-core and https://wiki.php.net/rfc/php_namespace_policy have been opposed, and I anticipate disagreement on any of those from https://externals.io/message/110711 Adopting namespaces without having any form of consensus on the way namespaces would be set up seems like it would be a potential source of language inconsistency and making it harder to learn, if some core functions are PHP\strings\tolower_c_locale(), some are iterable\something(), others are Ext\Graphics\draw_line()`, etc. Thanks, - Tyson