https://kotlinlang.org
Join Slack
What is the best code to create `List<DataA>` and `List<DataB>` starting from a `List&lt...
# getting-started
d
What is the best code to create 
List<DataA>
and 
List<DataB>
starting from a 
List<Source>
?
Copy code
data class Source {
	val label
	val valueA
	val valueB
}

data class DataA {
	val label
	val valueA
}

data class DataB {
	val label
	val valueB
}
n
honestly unless the list is giant, just map over List<Source> twice
👍 1
a
d
@nanodeath I was thinking there was a way to create both from the same loop
n
I mean, maybe yes, but it's going to be a mess
d
ok
a
It’s still linear O(n) so don’t worry.
n
you can probably do 
.asSequence().flatMap { sequenceOf(DataA, DataB) }.partitionBy { it is DataA }
kind of a thing, but ew
d
maybe I could just loop the list with a simple for loop?
n
imperative might be the way to go here
➕ 1
so, yeah 🙂
d
yes, I was thinking that 😉
n
some people get a bit hung up on doing a functional style for everything, but at least in Kotlin that's not always viable. so long as it's self-contained in a nice little method, should be just fine.
👍 2
d
yes, you are right
n
The functional style here is a bit tricky and may not work so great in Kotlin, I'm not sure
In python though you'd start by writing a lazy generator that yields pairs
And then there's a way to map an iterable of pairs onto two lists
a
It depends… the most important is to copy elements to array with pre-allocated capacity. The rest is case of style. But I assume 
map
pre-allocates array to be faster that’s why it’s probably better because developers usually forget about it when doing it with 
for
loop.
Copy code
val arrayOfZeros = IntArray(size) //equivalent in Java: new int[size]
e
https://pl.kotl.in/qoEJoW3qM doing it functionally seems fine to me in this case
➕ 5
if it had more cases like only including A or B under some conditions, then maybe this wouldn't be the best, but with the current constraints it is straightforward
n
no shit, this unzip method is awesome
😂 1
d
it looks good 🙂 but yes, it would just work in this particular case
it wouldn’t work with 3 lists, for example
n
hey, you can't go changing the requirements now 🙂
😉 1
s
You could argue an 
unzip()
for 
Triple
ought to exist in the stdlib also (or its easy enough to make yourself). I wonder what the generic version ought to look like.
s
The generic version would be transposing a list of lists
m
my first instinct was folding over the list to a pair of mutable lists; but yeah just making two mutable lists beforehand, looping over the sources and just putting them in, and then returning the lists out of a function is probably the best to begin with.
n
@ephemient nice, I didn't realize Kotlin had unzip
Unfortunately Kotlins zip and unzip only work for two things though
So the solution wouldn't generalize to three lists
But yeah, IMHO this sort of thing is why Kotlin needs tuples
zip and unzip should both operate on arbitrary ary-ness
(or at least, up to N = 9)
(or something reasonable)
e
Kotlin has specialized kotlin.jvm.functions.Function0..Function22 clases (why 22? I dunno, but Scala's specialized Function and Tuple classes also go up to 22)
n
I don't understand how a language with destructuring can eliminate tuples because "it's better to name things in a data structure" with a straight face
Data class not data structure
n
dunno, I agree with it. Pairs are just super convenient, and Triples are...kinda awkward? it's nice to have named fields, anyway. (I'm also not a big fan of destructuring.)
e
names are nice, but being able to perform operations like zip, unzip, cartesian product on larger tuples would also be nice
if there were a way to write generic code over any data class, we could have both. but I don't see a good design for it
this kind of code works now but it's a ludicrously terrible idea without support from the type system
Untitled.kt
n
@nanodeath so you would write:
Copy code
for (x in zip(firstList, secondList)) {
    // x.first, x.second
}
?
n
you got me, destructuring is great for iterating over pairs and entries 🙂 I avoid writing 
.first
and 
.second
and 
.key
and 
.value
whenever I can
but you can destructure data classes too, which...dunno, just never use that feature.
n
yeah, if you write a generic function like 
zip
though you don't really have anything intelligent to call the entries though
that's why tuples are mostly nice in generic code
it's annoying that kotlin doesn't support zipping three lists together
i agree if you have a data class with nice names there's probably less reason to use destructuring, unless you are using the variables a lot and really want the shorter names
m
n
ehh this is mostly good as a highlight of performance pitfalls of functional programs tbh
fold/reduce over List + is kind of a no-no, makes things quadratic
m
And using mutableList and add?
That is O(1)
n
Yeah that would work
Ideally reserving capacity first
👍 1
4 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by