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