Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112596
User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396
Mime-Version: 1.0
Message-ID: <cfde924d-ab5d-4a4c-a00e-ba21cfe94305@www.fastmail.com>
In-Reply-To: 
 <DM6PR07MB661889A16CBBCCC6AD0032F7F9DF0@DM6PR07MB6618.namprd07.prod.outlook.com>
References: 
 <DM6PR07MB661827026586104D5DEDAA64F9C20@DM6PR07MB6618.namprd07.prod.outlook.com>
 <CAESVnVoDShD_R0qRizmz06Whr4smEPOvy8jCCBJshKGw1jZ9zQ@mail.gmail.com>
 <DM6PR07MB6618A07A2EC02D44E132F18FF9DF0@DM6PR07MB6618.namprd07.prod.outlook.com>
 <477208c5-331d-671e-a8f4-199a751f0a04@processus.org>
 <DM6PR07MB661889A16CBBCCC6AD0032F7F9DF0@DM6PR07MB6618.namprd07.prod.outlook.com>
Date: Tue, 22 Dec 2020 10:20:40 -0600
To: "php internals" <internals@lists.php.net>
 =?UTF-8?Q?iterables?=
Content-Type: text/plain
Subject: =?UTF-8?Q?Re:_[PHP-DEV]_Straw_poll:_Naming_for_`*any()`_and_`*all()`_on_?=
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Dec 22, 2020, at 9:27 AM, tyson andre wrote:
> Hi Pierre,
> 
> > This is the kind of reasoning I fully support usually, I do maintain a 
> > few libraries for multiple PHP versions as most people in this list and 
> > make things easily polifyllable is something I'm sensible to.
> > 
> > Nevertheless, the language and its standard library has to evolve at 
> > some point. For enumerable objects PHP terribly lacks a complete and 
> > convenient API for developers. By putting those methods in the global 
> > namespace, you make those methods usage much less fluent for many 
> > developers that uses a decent IDE. It'd be a great thing to have a 
> > compete OO-based (interface based) API for collection methods. any() and 
> > all() methods are only the start, in my opinion, of much greater 
> > improvements in that regard, and I'd very much love to have those 
> > autocompleted by IDE on pretty much everything that is iterable.
> > 
> > That's just an opinion, I'd love to see it evolve towards an 
> > object-oriented API.
> 
> 1. If you're talking about adding default methods to Traversables,
>    default method implementations would be a major RFC of their own
>    for implementation and discussions on guidelines for using them internally.
> 
>    It may raise questions such as "why still have both traits and interfaces".
> 
>    Some may object to adding too many default methods to the 
> completions for an IDE
>    or naming conflicts in projects.
> 2. I'd find it useful to add, though there may be considerable 
> discussion over what belongs 
>    in an API for collection methods, whether they make sense with 
> SplObjectStorage, etc.
> 3. The pipe operator RFC may be a bit more fluent if a revised version 
> is accepted - https://externals.io/message/112558#112574
> 
>    `$exists = create_collection() |> user_defined_filter($$) |> 
> someprefix_any($$)` (possibly different syntax)
> 
> 4. I'd still want to add this functionality for arrays. Limiting 
> any/all to arrays only would be artificial,
>    and projects can use both if `->any()` was added by a different RFC 
>    (both count()/Countable->count() syntaxes are used in php code)

For those answering in the straw poll, note that the longer the prefix, the uglier chained calls will get.  Whether that's done with pipe or something else, expect to be typing that prefix a lot.  That's why I am OK with most options except `iterable_`, because that's a lot of needless typing.

--Larry Garfield