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

Hi Sara Golemon, > This is probably going to be a terrible idea because it involves a little magic but... > > "iterable" is already a forbidden userspace class name since it's reserved for > the psuedo-type which is a union of Traversable | array. > > What if we went ahead and defined an actual (abstract-final) V6°IïÞ > úIÎMÙ¾iterable class.  The parser rules which treat > iterable as a special type still apply, so we never try to match > instances of class iterable, but what we can do is define methods on > it. > > class Iterable { >    static public function any(iterable $iter, Callable $predicate): bool { ... } >    static public function all(iterable $iter, Callable $predicate): bool { ... } > } > > Then the API is both 100% searchable (the man page for iterable can explain that it's a > pseudo-type AND that it has helper methods), and intuitive to read/write. > > if (iterable::any($iter, fn($elem) => $elem === 'foo')) { > > } My objections to that are: 1. As mentioned in https://wiki.php.net/rfc/any_all_on_iterable_straw_poll#rejected_choices , I'd objected to static methods in general because it would be inconvenient to polyfill (magic such as __callStatic or disable_classes might be possible but inconvenient and integrate poorly with IDEs/analyzers) (if more than 2/3rs of php developers are in favor of more comprehensive functionality later on, such as none(), first(), etc.) 2. The name iterable::any would make it impossible to polyfill iterable::any()/all() in php 8.0 without using PECLS that modify the internals of php in unsafe ways (class_alias also forbids 'iterable' as an alias). I'd still prefer IterUtils/IterableUtils:: over iterable::. 3. For these reasons, I assume static methods have been fairly unpopular on functionality not associated with an object instance, but the main reason may be something else. Also, on an off-topic note, abstract final is forbidden for userland classes, so making it have those flags would be surprising for uses of Reflection such as code stub generators, but forbidding the constructor would be close enough. Although I think abstract final should be allowed like it is in java, I think RFCs that proposed allowing abstract final failed by a large margin years ago and I don't plan to reopen that. Thanks, - Tyson