Hi Dik Takken, > I would love to see this come to PHP. I also do a lot of Python > development and I really like its operators module, which provides > function equivalents to the intrinsic Python operators. Have a look: > > https://docs.python.org/3/library/operator.html > > Although the any() and all() functions are my favorites, having the full > range of operator functions would be great. That could ultimately yield > a proper counterpart to the range of array_* functions which support any > iterable in stead of just arrays. Think of a keys() function that is a > generalization of array_keys().
Operator overloading was the subject of https://wiki.php.net/rfc/userspace_operator_overloading#vote which had a 38-28 vote, which didn't meet the 2/3 voting threshold. > This reminds me of the iter library that Nikita created: > > https://github.com/nikic/iter > > So yes, this can also be done in user space. Having it built into the language has advantages though: > > * High adoption rates, making lots of existing PHP code more concise > * Possibly better performance Strangely, if I remember correctly, I've had better performance looping inline and calling closures than calling array_map when there were a large number of elements. I think opcache's inferences and the fact there's no switch from internals back to the php vm was part of the reason for it. (and the tracking of stack frames?) The readability's my main reason for making it native. I'd wondered if there'd be a benefit to preloading where we replace C functions with native php functions (optionally JITted) if there's an expected benefit, like HHVM does for parts of its standard library, but again out of scope. > Regarding performance: Since we already have opcodes for handling > operators, it may be possible to extend these to consume arbitrary > numbers of operands from iterables. Then, an operator function like > any() would compile into its equivalent operator opcode. Finally, that > opcode can probably be JIT compiled into a tight loop in machine code. That's definitely something I'd want to see for array_map/array_filter. There's the question of whether it'd be reasonable to omit stack frames or whether it's practical to create fake frames with parameter values for debug_backtrace(). Larry Garfield also did some work on python-like list comprehensions, though it's still in draft. Automatically rewriting array_map(), array_filter(), all(), etc. to list comprehensions and then to JITted code could see a nice performance benefit in benefit, but this is out of scope of the RFC I'm working on See https://externals.io/message/104637 > So a +1 from me for adding any() and all() but let us also consider the > general problem of lacking iterable support in PHP. Perhaps that could > be the subject of a followup RFC. Part of the issue is what the return type would be. For example, reduce(iterable, callable, $initial = null) could work well, but what should map() do `map(callable, iterable $values): iterable` - should it preserve keys, should it return an array|Generator, array|CustomTraversable, something depending on the object type, etc. (Generator performance seems like it'd be worse than eager evaluation) Regards, Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
