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

On Sat, Dec 26, 2020 at 10:02 AM Niklas Keller <me@kelunik.com> wrote: >> >> 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. > > > Hey Levi, > > while I agree that namespaces were designed for this, I think > all and any are too generic names, > even in a namespace. > > I think Java's naming with any_match / all_match could be a good fit. I agree they are a bit generic, especially because we may need to distinguish between keys and values. For that reason I prefer Spl\all_values and Spl\any_value. We can make it read very well with named parameters if that's your thing: ``` if (all_values($input, 'is_int')) // or alternatively: if (all_values(of: $input, satisfy: 'is_int')) ``` I wouldn't put too much excitement into making highly readable English; I mention it mostly to point out that I think we should put at least a little bit of effort into parameter names for any new library additions. > If promises / futures make it into core in the future, there will be a need for an > any / all function combining > promises / futures. > > Maybe these should be named array_* and all array functions > should be adjusted to work with iterators? Many of them can't work efficiently on iterables or have idiosyncrasies. I don't think this the way forward either. ----- I am hopeful we can add at least a few other functions alongside these additions to help establish good patterns for functions that work with iterables, as there are quite a few of them. At least we should add some form of reduce, as any and all are forms of reducers.