Title
d

Daniele B

09/29/2020, 11:30 PM
What is the best code to create
``List<DataA>``
and
``List<DataB>``
starting from a
``List<Source>``
?
``````data class Source {
val label
val valueA
val valueB
}

data class DataA {
val label
val valueA
}

data class DataB {
val label
val valueB
}``````
n

nanodeath

09/29/2020, 11:35 PM
honestly unless the list is giant, just map over List<Source> twice
👍 1
d

Daniele B

09/29/2020, 11:36 PM
@nanodeath I was thinking there was a way to create both from the same loop
n

nanodeath

09/29/2020, 11:36 PM
I mean, maybe yes, but it's going to be a mess
d

Daniele B

09/29/2020, 11:36 PM
ok
a

Ariel Bogdziewicz

09/29/2020, 11:37 PM
It’s still linear O(n) so don’t worry.
n

nanodeath

09/29/2020, 11:37 PM
you can probably do
``.asSequence().flatMap { sequenceOf(DataA, DataB) }.partitionBy { it is DataA }``
kind of a thing, but ew
d

Daniele B

09/29/2020, 11:37 PM
maybe I could just loop the list with a simple for loop?
n

nanodeath

09/29/2020, 11:38 PM
imperative might be the way to go here
1
so, yeah 🙂
d

Daniele B

09/29/2020, 11:38 PM
yes, I was thinking that 😉
n

nanodeath

09/29/2020, 11:39 PM
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

Daniele B

09/29/2020, 11:41 PM
yes, you are right
n

Nir

09/30/2020, 12:13 AM
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

Ariel Bogdziewicz

09/30/2020, 12:44 AM
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.
``val arrayOfZeros = IntArray(size) //equivalent in Java: new int[size]``
e

ephemient

09/30/2020, 12:47 AM
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

nanodeath

09/30/2020, 1:12 AM
no shit, this unzip method is awesome
😂 1
d

Daniele B

09/30/2020, 1:28 AM
it looks good 🙂 but yes, it would just work in this particular case
it wouldn’t work with 3 lists, for example
n

nanodeath

09/30/2020, 1:34 AM
hey, you can't go changing the requirements now 🙂
😉 1
s

spand

09/30/2020, 5:31 AM
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

Scott Christopher

09/30/2020, 6:58 AM
The generic version would be transposing a list of lists
m

Michael de Kaste

09/30/2020, 7:36 AM
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

Nir

09/30/2020, 1:31 PM
@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

ephemient

10/01/2020, 12:41 AM
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

Nir

10/01/2020, 3:10 AM
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

nanodeath

10/01/2020, 4:23 AM
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

ephemient

10/01/2020, 4:27 AM
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
n

Nir

10/01/2020, 1:59 PM
@nanodeath so you would write:
``````for (x in zip(firstList, secondList)) {
// x.first, x.second
}``````
?
n

nanodeath

10/01/2020, 3:19 PM
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

Nir

10/01/2020, 3:24 PM
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

Matias Reparaz

10/02/2020, 2:27 AM
n

Nir

10/02/2020, 2:30 AM
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

Matias Reparaz

10/02/2020, 2:44 AM
And using mutableList and add?
That is O(1)
n

Nir

10/02/2020, 2:58 AM
Yeah that would work
Ideally reserving capacity first
👍 1