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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
