Re: [VOTE] PHP\iterable\any() and all() on iterables
| From: | Mike Schinkel | Date: | Wed, 10 Feb 2021 16:14:28 +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-113133@lists.php.net to get a copy of this message | ||
> On Feb 8, 2021, at 7:37 PM, Kamil Tekiela <tekiela246@gmail.com> 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()/}>žL¥zL'Bû•“‰°
> !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.
Having self-describing function names is a good policy for userland code. However, and piggybacking
on what Larry Garfield just wrote, for language primitives that will be used often by many
developers and that have analogues in other languages, having short names works well.
By definition there are not tons of language primitives like these for developers to learn, at least
not when compared to userland code, and their shortness empowers developers to write more concise
code.
-Mike