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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
