>Kotlin's equivalent of LINQ doesn't use deferred evaluation.
Wow, I'm pretty surprised at that. Any kind of list comprehension/functional sub-language over collections seems like it ought to be deferred/lazy from the ground up. I'm doubly surprised at that from JetBrains.
Unfortunately it is so, so I wouldn't recommend it for large collections, or wherever performance considerations come into equation.
Let's peek at Kotlin's sources (_Filtering.kt):
public inline fun <T> Iterable<T>.filter(predicate: (T) -> Boolean): List<T> {
// note how it's allocating a new ArrayList<T> -
// Kotlin doesn't have a "new" keyword, but it's initializing it here
return filterTo(ArrayList<T>(), predicate)
}
And it redirects to filterTo:
public inline fun <T, C : MutableCollection<in T>> Iterable<T>.filterTo(destination: C, predicate: (T) -> Boolean): C {
for (element in this) if (predicate(element)) destination.add(element)
return destination
}
With this approach, if you're chaining several of these operations, you will end up allocating quite a few arraylists, one by one.
Note that without something like yield-return in place, writing your own collection-transforming extension functions with lazy evaluation won't be so clean and easy either
Since it has 100% interop with Java, you could work around this problem by using something like Guava - Iterables and FluentIterable are based on iterators as they should.
They use static helper methods, all you need to do is to snap out some extension functions in Kotlin to serve as bindings to Guava. The only problem, especially on Android, is that Guava's notoriously big.
Kotlin is good, I'm not hating on it, but mature? Not yet. Nicer than C#? Best of luck, but not with this type of shortcomings
* new (lazy) extension functions would be getting in the way of standard ones, you would need a paralel naming convention (perhaps one borrowed from LINQ, where map = select, filter = where, fold = aggregate and so on) and developers would still confuse one with another.
* unless we agree on one canonical implementation, yours would be different than mine, easy to see how it could become a mess.
If there is a better approach which removes these obstacles, someone let me know
Wow, I'm pretty surprised at that. Any kind of list comprehension/functional sub-language over collections seems like it ought to be deferred/lazy from the ground up. I'm doubly surprised at that from JetBrains.