Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112597
To: internals@lists.php.net
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>
Message-ID: <99d8aa79-1bd1-dccb-b551-80c728039949@processus.org>
Date: Tue, 22 Dec 2020 17:46:56 +0100
MIME-Version: 1.0
In-Reply-To: <DM6PR07MB661889A16CBBCCC6AD0032F7F9DF0@DM6PR07MB6618.namprd07.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Subject: Re: [PHP-DEV] Straw poll: Naming for `*any()` and `*all()` on
 iterables
From: pierre-php@processus.org (Pierre)

Le 22/12/2020 à 16:27, tyson andre a écrit :
> 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.

Hello again,

First things first, I'm sorry for answering to all instead of answering 
to the list.

The rest below.

> 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.
Adding default methods to interface would be something I'd love, and 
yes, collection methods could be implemented this way, yet I agree with 
you this would need two RFC, one for default methods, the other for a 
collection API. Doesn't sound impossible to me, just very hard to have 
something people will all agree on to :)
>     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.
Sure, every addition poses that risk. I think there's no easy way to go 
around that. But in the other side, it'll probably conflict with 
libraries implementing the same thing, thus obsoleting those. They could 
actually be polyfilled as well and use core's methods behind the scenes.
> 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.
I think I would start without thinking about where they belong, by 
writing clean new interfaces first, then see how it comes when applying 
them to existing types one by one.
> 3. The pipe operator RFC may be a bit more fluent if a revised version is accepted - https://externals.io/message/112558#112574
It's fluent in reading, but it's not really in writing code, since when 
I'll type ctrl+space to have autocompletion, it'll autocomplete on the 
global standard library namespace and I'll have thousands of possible 
functions to call.
>     `$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)

I always thought that arrays should probably be promoted to objects 
somehow, it would make sense. Having array being iterable but not 
traversable always looked very weird to me. And I'd love to call 
$myArray->first(), $myArray->keys(), $myArray->any() etc... as well as 
for any collection, if collections as objects/interface did exist !

Regards,

--

Pierre