Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112587
To: tyson andre <tysonandre775@hotmail.com>, Sara Golemon <pollita@php.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
References: <DM6PR07MB661827026586104D5DEDAA64F9C20@DM6PR07MB6618.namprd07.prod.outlook.com>
 <CAESVnVoDShD_R0qRizmz06Whr4smEPOvy8jCCBJshKGw1jZ9zQ@mail.gmail.com>
 <DM6PR07MB6618A07A2EC02D44E132F18FF9DF0@DM6PR07MB6618.namprd07.prod.outlook.com>
Message-ID: <477208c5-331d-671e-a8f4-199a751f0a04@processus.org>
Date: Tue, 22 Dec 2020 08:37:37 +0100
MIME-Version: 1.0
In-Reply-To: <DM6PR07MB6618A07A2EC02D44E132F18FF9DF0@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 à 01:48, tyson andre a écrit :
> Hi Sara Golemon,
>
>> This is probably going to be a terrible idea because it involves a little magic but...
>>
>> "iterable" is already a forbidden userspace class name since it's reserved for the psuedo-type which is a union of `Traversable | array`.
>>
>> What if we went ahead and defined an actual (abstract-final) `iterable` class.  The parser rules which treat `iterable` as a special type still apply, so we never try to match instances of class `iterable`, but what we can do is define methods on it.
>>
>> class Iterable {
>>      static public function any(iterable $iter, Callable $predicate): bool { ... }
>>      static public function all(iterable $iter, Callable $predicate): bool { ... }
>> }
>>
>> Then the API is both 100% searchable (the man page for iterable can explain that it's a pseudo-type AND that it has helper methods), and intuitive to read/write.
>>
>> if (iterable::any($iter, fn($elem) => $elem === 'foo')) {
>>
>> }
> My objections to that are:
>
> 1. As mentioned in https://wiki.php.net/rfc/any_all_on_iterable_straw_poll#rejected_choices , I'd objected to static methods in general because it would be inconvenient to polyfill
>      (magic such as __callStatic or disable_classes might be possible but inconvenient and integrate poorly with IDEs/analyzers)
>
>      (if more than 2/3rs of php developers are in favor of more comprehensive functionality later on, such as none(), first(), etc.)
> 2. The name `iterable::any` would make it impossible to polyfill iterable::any()/all() in php 8.0 without using PECLS that modify the internals of php in unsafe ways (class_alias also forbids 'iterable' as an alias). I'd still prefer IterUtils/IterableUtils:: over iterable::.
> 3. For these reasons, I assume static methods have been fairly unpopular on functionality not associated with an object instance, but the main reason may be something else.
>
> Also, on an off-topic note, `abstract final` is forbidden for userland classes, so making it have those flags would be surprising for uses of Reflection such as code stub generators,
> but forbidding the constructor would be close enough.
> Although I think `abstract final` should be allowed like it is in java,
> I think RFCs that proposed allowing `abstract final` failed by a large margin years ago and I don't plan to reopen that.
>
> Thanks,
> - Tyson

Hello,

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.

Regards,

Pierre