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)
   

Thanks,
-Tyson

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to