Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112574
User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396
Mime-Version: 1.0
Message-ID: <46be5a21-6fcd-469e-a214-09864ffaff23@www.fastmail.com>
In-Reply-To: 
 <DM6PR07MB6618CB9909CDE7720A17F7A0F9C10@DM6PR07MB6618.namprd07.prod.outlook.com>
References: 
 <DM6PR07MB661827026586104D5DEDAA64F9C20@DM6PR07MB6618.namprd07.prod.outlook.com>
 <f974ff63-1257-4f3b-8dce-95eb72726dc7@CO1NAM11FT064.eop-nam11.prod.protection.outlook.com>
 <DM6PR07MB6618CB9909CDE7720A17F7A0F9C10@DM6PR07MB6618.namprd07.prod.outlook.com>
Date: Mon, 21 Dec 2020 09:56:48 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: =?UTF-8?Q?Re:_[PHP-DEV]_Re:_Straw_poll:_Naming_for_`*any()`_and_`*all()`?=
 =?UTF-8?Q?_on_iterables?=
From: larry@garfieldtech.com ("Larry Garfield")

On Sun, Dec 20, 2020, at 5:56 PM, tyson andre wrote:
> Hi Mark Randall,
> 
> > These functions make sense. However I think we need to give renewed 
> > consideration to:
> > 
> > $itr->all();
> > $itr->some(...);
> 
> That wouldn't help for arrays, which would be the most common use case 
> - I don't remember seeing an RFC for 
> https://github.com/nikic/scalar_objects and that is a much larger 
> language change.
> 
> This also wouldn't help if I wanted something that could be used on any 
> Traversable.
> Currently, there's no support for default methods for interfaces such 
> as Iterator/IteratorAggregate - I think I saw some discussion of that.
> (e.g. to check for any()/all() on generators, user-defined classes, etc)
> Backwards compatibility of method signatures with the same names that 
> were written before default methods were added would be a concern, 
> though.
> (https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html)

Related: I am planning to get back to the pipe operator at some point during the 8.1 cycle; right now the only blocker is finishing the partial function application RFC (which is partially completed, no pun intended, but currently lagging due to lack of time; Ilija was working on it but is focused on enums at the moment).  Assuming pipe passes (since the feedback was quite positive last time with the caveat of wanting partials first), that would open up the potential for functions that return iterator-expecting functions to be used in pipes.  To wit:

function i_map(callable $fn): callable {
  return function (iterable $list) use ($fn) {
    foreach ($list as $k => $v) {
      yield $fn($v, $k);
    }
  }
}

$any_iterable |> i_map($some_callable) |> i_filter($other_callable) |> any($boolean_check);

That would obviate the need to have proper methods on iterables as the combination of |> and higher order functions gives a similarly chainable syntax without the need to think about what objects have what methods on them at compile time.

It's not perfect, but I think it's a good solution to a long-standing challenge.  (Whether or not such higher order functions belong in the standard lib is debatable; it probably depends on what the performance difference is.)

--Larry Garfield