Re: [VOTE] PHP\iterable\any() and all() on iterables
| From: | Larry Garfield | Date: | Wed, 10 Feb 2021 15:50:37 +0000 |
| Subject: | Re: [VOTE] PHP\iterable\any() and all() on iterables | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-113132@lists.php.net to get a copy of this message | ||
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())1$e�
> öÀ•@dÏî3ä 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