Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113132
User-Agent: Cyrus-JMAP/3.5.0-alpha0-93-gef6c4048e6-fm-20210128.002-gef6c4048
Mime-Version: 1.0
Message-ID: <abf7b2cd-5537-4067-9ac3-5ef3ffa4d0c3@www.fastmail.com>
In-Reply-To: 
 <CAGBsUrcJDkQKJnKV1XrLksJi64Uvhja9XQr21KHHMCm8wZ+D2w@mail.gmail.com>
References: 
 <DM6PR07MB66189594D6D3B6D820E4A5FBF98F9@DM6PR07MB6618.namprd07.prod.outlook.com>
 <77dfe9e5-a6d1-4a41-bceb-454a65cf34d0@www.fastmail.com>
 <DM6PR07MB6618999C8F1AAC35BF2F8C87F98F9@DM6PR07MB6618.namprd07.prod.outlook.com>
 <f1abc6fd-dfad-4cd4-a124-58475312fa86@www.fastmail.com>
 <DM6PR07MB66184FDB329A71B371883C54F98E9@DM6PR07MB6618.namprd07.prod.outlook.com>
 <CAGBsUrcJDkQKJnKV1XrLksJi64Uvhja9XQr21KHHMCm8wZ+D2w@mail.gmail.com>
Date: Wed, 10 Feb 2021 09:50:37 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [VOTE] PHP\iterable\any() and all() on iterables
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Feb 8, 2021, at 6:37 PM, Kamil Tekiela wrote:
> Hi Tyson,
> 
> Thanks for the RFC. I have to say that I like the core concept and the
> motivation behind it. However, let me explain why I voted No.
> 
> 1. As others have said I think that the scope is too small. If we are going
> to create that namespace then I would like to see more functions/classes in
> that namespace.
> 2. I don't like the name. I know the namespace might provide some guidance
> of what the function is, but namespaces are often imported. What we are
> left with in the code is then `any()`/`all()` that doesn't have a
> self-describing name. any_values is better but still doesn't describe the
> action that the function will take. I am a strong believer that methods and
> functions should be called with verbs which describe an action. e.g.
> search, filter, combine, merge, etc. There can always be exceptions but
> there should be a good reason to justify such an exception.

The naming is fine, I think.  any(), all(), first(), etc. have long-standing meaning in multiple languages.  As long as we're using them consistently with convention I don't think there's any reason to introduce longer names, especially when, if done correctly, the stuff in this namespace would be highly chainable and give us a close-enough to comprehensions.  Short-sweet-but-clear is a good guideline on this one.

--Larry Garfield