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