I am trying to find better way to chain the filter and map operators in Kotlin. What I want to do is to filter the null items before going to the map operator.
I was able to chain them, but the compiler complained about the nullability of my list items.
class Person(val age : String?)
fun foo(age :String){
// require non-null age
}
The sample usage was:
val list = mutableListOf(Person("3"), Person("2"))
list.filter{ it.age != null }.map{ foo(it.age) }
// The IDE wants me to add !!
So why can't Kotlin infer the nullability? The filtered (all non-null) items passed down to map should had been filtered to ensure that they are non-null.
You can replace filter and map with one method mapNotNull:
val list2 = list.mapNotNull { it.age }
This case may seem easy for a human, but technically speaking it would be really hard for the compiler to understand that after filtering it is a list of people objects, but with different type of the age property than original.
If you don't use a whole people instance at map() stage then I think the easiest would be to do:
list
.mapNotNull { it.age }
.map(::foo)
Or, if your foo() can't return nulls:
list.mapNotNull { it.age?.let(::foo) }
But I think this is less readable. Or you can just use !! - it's not that bad if we know what we're doing.
You can use the Iterable<T>.filterNotNull() extension function here which will return a list of the non-nullable type.
In your case, the compiler just isn't advanced enough to smart-cast the filtered list, it would be quite a lot to ask. So if you need to use filter specifically you would have to add an assertion.
Related
how can i sort 2D mutable list of array by the first element of array?
val books = mutableListOf<Any>(
listof("abc","b",1),
listof("abb","y",2),
listof("abcl"."i",3)
)
i want to get sort this mutablelist by alphabetical order of the first element of each list.
output should be
[listof("abb","y",2), listof("abc","b",1), listof("abcl"."i",3) ]
You can do
books.sortBy { (it as List<*>).first() as String }
This is difficult, because you have very limited type information.
If you the elements of the inner lists always have three values of type String, String, Integer, you should probably use a triple:
val books = mutableListOf<Triple<String, String, Int>>(
Triple("abc","b",1),
Triple("abb","y",2),
Triple("abcl","i",3)
)
books.sortBy { t -> t.first }
If the inner lists are always lists, but with different lengths and types, but it is known that the are always strings you can do something like
val books = mutableListOf<List<Any>>(
listOf("abc","b",1),
listOf("abb","y",2),
listOf("abcl","i",3)
)
books.sortBy { t -> t.first() as String }
If you don't know any type information, and books is truly a MutableList<Any>, then you cannot compare: you don't what you are comparing.
You've got two problems here:
your list contains elements of Any, which doesn't imply any kind of "first element"
you can only compare things which implement Comparable (unless you pass in your own comparator, or do your own comparison logic in the sorting function)
First, if this list really is supposed to hold "lists of elements", then you should make that part of the type. We can use the general Collection type (or Iterable which it extends):
val books = mutableListOf<Collection<Any>>(
listof("abc","b",1),
...
Unfortunately that doesn't work for arrays, which are their own thing. If you want to be able to mix and match, you need to keep the MutableList<Any> type, and do some type checking in the sort function:
// all kinds of things going in here
val books = mutableListOf<Any>(
listOf("abc","b",1),
arrayOf("abb","y",2),
setOf("abcl","i",3)
)
books.sortedBy {
when(it) {
is Collection<*> -> it.first().toString()
is Array<*> -> it.first().toString()
// or your fallback could just be it.toString()
else -> throw Exception("can't compare this thing")
}
}
That example demonstrates your second problem too - how to sort a bunch of Anys. Since you said you want them alphabetically sorted (and without knowing what you're going to put in there besides strings and numbers) one approach is to just call toString() on everything.
That's one of the few methods Any has, so if you can't be more specific about the types in your "lists", you can at least sort on that. Whether it'll be any use out-of-the-box depends on the objects you put in there!
I want to write a kotlin function that can filter lists.
The filtering I want to do is pretty much an ID whitelisting, so imagine that I have a list of string IDs that are allowed. Then the function should remove all objects of the input list that have an ID not in the whitelist. Pretty basic stuff really.
The problem I guess is that I want it really generic. And I am wondering if it is possible in kotlin to take in a list of Any, but that have a property id?
Or is it only possible by creating an interface that all objects need to implement?
fun <T> List<T>.filterUnknownIds(getId: T.() -> String): List<T> = filter { it.getId() in whitelistedIds }
Assuming whitelistedIds is a list of strings. I didn't compile the code as I'm on mobile but should work.
It might be a stupid question, but I am not sure whether to use indexOfFirst() or find() as both "Returns the first element matching the given [predicate]". The only difference is that one returns -1 and other null. When should I use indexOfFirst() or find(). Is there any advantage of one over other. Consider the following code snippet.
private val mPersonList = mutableListOf<Person>()
private fun findPerson(person: Person) {
val position = mPersonList.indexOfFirst { it.name == person.name }
if (position != -1) {
doSomethingWithPerson(mPersonList[position])
}
}
private fun findPersonWithFind(person: Person) {
val foundPerson = mPersonList.find { it.name == person.name }
foundPerson?.let { doSomethingWithPerson(it) }
}
private fun doSomethingWithPerson(foundPerson: Person) {
//Do something
}
Both functions do nearly the same thing: they both locate the first matching item in a list or array (i.e. the first one for which the given predicate returns true).
The differences between them are subtle:
Most obviously, indexOfFirst() gives the index of the matching item, while find() gives the item itself.
Obviously, if you have the index, you can easily get the matching item. (And, if the list is random-access, such as an ArrayList, then that's very efficient — much less so if it's not, such as a LinkedList.) Whereas if you only have the item, then you can't find its index without calling find, indexOf, or indexOfFirst again!
So if you need to know the index, then only indexOfFirst() will do; but if you don't, then find() may be marginally simpler.
The code in the question falls into the latter category: findPerson() gets the position but uses it only to index into the list. So that's a little more long-winded, and (if the list isn't random-access) potentially a lot slower, than findPersonWithFind().
Second, as you say, if no matching item is found, indexOfFirst() returns -1, while find() returns null.
Kotlin provides many ways to use nulls safely (such as the safe-call ?. operator, the elvis ?: operator, smart-casting, extension functions on nullable receivers, and many helpful functions in the standard library). But there are no equivalents for dealing with -1, so using find() is likely to make it easier to safely handle the not-found case.
By the way, the nullability is made clear in the alternative name for find(), which is firstOrNull() — though that also has overloads which take no predicate and simply return the very first item in the list if it's not empty. (The standard library is moving toward …OrNull() function names, probably because it makes the nullability very clear, especially when it's a common naming convention.)
So, which one you use depends on your needs.
It's also worth being aware of some related functions. All of them have equivalents which find the last matching item: findLast()/lastOrNull(), and indexOfLast().
There's also the older indexOf() function, which checks for (equality with) a given object, instead of using a predicate. (That, too, returns -1 if not found, which is probably why indexOfFirst() and indexOfLast() do the same.) Though if the list is sorted, a binarySearch() or binarySearchBy is likely to be a lot faster than a full scan.
i am trying to understand when to use the "in" keyword in generics as opposed to the "out" keyword (which allows assigning to subclasses).
I am actually following this tutorial if it matters.
Lets say we have the following class defintiion:
class ParameterizedConsumer<in T> {
fun toString(value: T): String {
return value.toString()
}
}
How does this even compile since value is not guaranteed to be a String ? is this what the in keyword does ? it tells the class that there is a guarantee the type wont be any other subclass ? I am just not clear on the usecase for it, can you help ?
the tutorial says i will be able to call the following but i am lost as to what it has changed:
val parameterizedConsumer = ParameterizedConsumer<Number>()
val ref: ParameterizedConsumer<Double> = parameterizedConsumer
assertTrue(ref is ParameterizedConsumer<Double>)
UPDATE: I get it now. Out means you can downcast when producing. and "In" means you can downcast when assigning.
So in java this is not allowed:
// Java
void demo(Source<String> strs) {
Source<Object> objects = strs; // !!! Not allowed in Java
// ...
}
but in kotlin we can fix that if we use the "out" keyword we can assign to a downcasted class (subclass). likewise with "in" we can pass in a subclass into the class internally to use but not outwardly.
it tells the class that there is a guarantee the type wont be any other subclass ? I am just not clear on the usecase for it, can you help ?
Say you have a function that wants to add some items to a list you supply. The items are of type Int.
Question: what kinds of list are acceptable to this function?
Answer: MutableList<Int>, MutableList<Number>, MutableList<Any>. Or, in short, MutableList<in Int>.
In the same spirit, let's explain the out projection.
Say you have a function that wants to get some elements from a list you supply. The items are of type Future.
Question: what kinds of list are acceptable to this function?
Answer: List<Future>, List<RunnableFuture>, List<ScheduledFuture>... or, in short, List<out Future>.
I'll answer part of your question
How does this even compile since value is not guaranteed to be a String
So what? You can call .toString() on any type. That's how you get a string you'll be returning.
Both of these interfaces define only one method
public operator fun iterator(): Iterator<T>
Documentation says Sequence is meant to be lazy. But isn't Iterable lazy too (unless backed by a Collection)?
The key difference lies in the semantics and the implementation of the stdlib extension functions for Iterable<T> and Sequence<T>.
For Sequence<T>, the extension functions perform lazily where possible, similarly to Java Streams intermediate operations. For example, Sequence<T>.map { ... } returns another Sequence<R> and does not actually process the items until a terminal operation like toList or fold is called.
Consider this code:
val seq = sequenceOf(1, 2)
val seqMapped: Sequence<Int> = seq.map { print("$it "); it * it } // intermediate
print("before sum ")
val sum = seqMapped.sum() // terminal
It prints:
before sum 1 2
Sequence<T> is intended for lazy usage and efficient pipelining when you want to reduce the work done in terminal operations as much as possible, same to Java Streams. However, laziness introduces some overhead, which is undesirable for common simple transformations of smaller collections and makes them less performant.
In general, there is no good way to determine when it is needed, so in Kotlin stdlib laziness is made explicit and extracted to the Sequence<T> interface to avoid using it on all the Iterables by default.
For Iterable<T>, on contrary, the extension functions with intermediate operation semantics work eagerly, process the items right away and return another Iterable. For example, Iterable<T>.map { ... } returns a List<R> with the mapping results in it.
The equivalent code for Iterable:
val lst = listOf(1, 2)
val lstMapped: List<Int> = lst.map { print("$it "); it * it }
print("before sum ")
val sum = lstMapped.sum()
This prints out:
1 2 before sum
As said above, Iterable<T> is non-lazy by default, and this solution shows itself well: in most cases it has good locality of reference thus taking advantage of CPU cache, prediction, prefetching etc. so that even multiple copying of a collection still works good enough and performs better in simple cases with small collections.
If you need more control over the evaluation pipeline, there is an explicit conversion to a lazy sequence with Iterable<T>.asSequence() function.
Completing hotkey's answer:
It is important to notice how Sequence and Iterable iterates throughout your elements:
Sequence example:
list.asSequence().filter { field ->
Log.d("Filter", "filter")
field.value > 0
}.map {
Log.d("Map", "Map")
}.forEach {
Log.d("Each", "Each")
}
Log result:
filter - Map - Each; filter - Map - Each
Iterable example:
list.filter { field ->
Log.d("Filter", "filter")
field.value > 0
}.map {
Log.d("Map", "Map")
}.forEach {
Log.d("Each", "Each")
}
filter - filter - Map - Map - Each - Each
Iterable is mapped to the java.lang.Iterable interface on the
JVM, and is implemented by commonly used collections, like List or
Set. The collection extension functions on these are evaluated
eagerly, which means they all immediately process all elements in
their input and return a new collection containing the result.
Here’s a simple example of using the collection functions to get the
names of the first five people in a list whose age is at least 21:
val people: List<Person> = getPeople()
val allowedEntrance = people
.filter { it.age >= 21 }
.map { it.name }
.take(5)
Target platform: JVMRunning on kotlin v. 1.3.61 First, the age check
is done for every single Person in the list, with the result put in a
brand new list. Then, the mapping to their names is done for every
Person who remained after the filter operator, ending up in yet
another new list (this is now a List<String>). Finally, there’s one
last new list created to contain the first five elements of the
previous list.
In contrast, Sequence is a new concept in Kotlin to represent a lazily
evaluated collection of values. The same collection extensions are
available for the Sequence interface, but these immediately return
Sequence instances that represent a processed state of the date, but
without actually processing any elements. To start processing, the
Sequence has to be terminated with a terminal operator, these are
basically a request to the Sequence to materialize the data it
represents in some concrete form. Examples include toList, toSet,
and sum, to mention just a few. When these are called, only the
minimum required number of elements will be processed to produce the
demanded result.
Transforming an existing collection to a Sequence is pretty
straightfoward, you just need to use the asSequence extension. As
mentioned above, you also need to add a terminal operator, otherwise
the Sequence will never do any processing (again, lazy!).
val people: List<Person> = getPeople()
val allowedEntrance = people.asSequence()
.filter { it.age >= 21 }
.map { it.name }
.take(5)
.toList()
Target platform: JVMRunning on kotlin v. 1.3.61 In this case, the
Person instances in the Sequence are each checked for their age, if
they pass, they have their name extracted, and then added to the
result list. This is repeated for each person in the original list
until there are five people found. At this point, the toList function
returns a list, and the rest of the people in the Sequence are not
processed.
There’s also something extra a Sequence is capable of: it can contain
an infinite number of items. With this in perspective, it makes sense
that operators work the way they do - an operator on an infinite
sequence could never return if it did its work eagerly.
As an example, here’s a sequence that will generate as many powers of
2 as required by its terminal operator (ignoring the fact that this
would quickly overflow):
generateSequence(1) { n -> n * 2 }
.take(20)
.forEach(::println)
You can find more here.
Iterable is good enough for most use cases, the way iteration is performed on them it works very well with caches because of the spatial locality. But the issue with them is that whole collection must pass through first intermediate operation before it moves to second and so on.
In sequence each item passes through the full pipeline before the next is handled.
This property can be determental to the performance of your code especially when iterating over large data set. so, if your terminal operation is very likely to terminate early then sequence should be preferred choice because you save by not performing unnecessary operations. for example
sequence.filter { getFilterPredicate() }
.map { getTransformation() }
.first { getSelector() }
In above case if first item satisfies the filter predicate and after map transformation meets the selection criteria then filter, map and first are invoked only once.
In case of iterable whole collection must first be filtered then mapped and then first selection starts