4 ms·
No, I don't think you understood it. There is a large qualitative gap between what you propose, and what Scala does: In Scala, it is an _one_ time effort to ma
by justthistime_ 11y ago
No, I don't think you understood it. There is a large qualitative gap between what you propose, and what Scala does:
In Scala, it is an _one_ time effort to make String act "like" collections, while the only solution Kotlin provides means doing the work manually _n_ times: At every call site of the string in question.
Kotlin developers also didn't feel like your point was too convincing: https://github.com/JetBrains/kotlin/blob/master/libraries/stdlib/src/generated/_Strings.kt https://github.com/JetBrains/kotlin/blob/master/libraries/st...
- mike_hearn 11y agoThat file contains the definitions of asList and asSequence, for example. If you're saying "but look at the other methods", that's not very convincing to me either because honestly I don't think having a fold method directly on String is very useful - if they scrapped a lot of those extension methods I'd be totally OK with that. At any rate, you never addressed the core point I raised. Saying "implicit resolution isn't related to implicit classes" doesn't seem very convincing. If solving that issue was so easy then why is the use of implicits so frequently identified as a performance issue for tools?