> On Feb 8, 2021, at 7:37 PM, Kamil Tekiela <tekiela...@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()`/`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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
