On Sun, Aug 30, 2020, at 3:43 PM, tyson andre wrote: > 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
I was just considering mentioning that. :-) I still would like to see comprehensions happen, but I'd need to partner with someone with more engine skill than I to actually implement it, plus the reception was somewhat lukewarm. I do think they're useful and would help with any/all/first type use cases, though. If someone reading this is interested, you know where to find me... --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
