https://kotlinlang.org logo
Title
j

James Richardson

12/11/2019, 2:19 PM
Something like headers.filterNot { it.first in noCopyHeaders }.toMap
s

Simon Kågedal Reimer

12/11/2019, 5:51 PM
Thanks, did not know about
.first
!
s

StavFX

12/11/2019, 6:50 PM
Minor, but - for
Map.Entry
it’ll be
.key
, not
.first
. The real improvement here is using
in
instead of
contains
, so I would combine Dominic’s and James’ answers to
headers.associate { it.toPair() }
   .filterKeys { it !in noCopyHeaders }
1
😍 1
s

Simon Kågedal Reimer

12/11/2019, 6:57 PM
That's wonderful!
m

Matteo Mirk

12/19/2019, 11:50 AM
Cool solution Stav! I was wondering, how about filtering the list before instantiating the map?
headers.filterNot { it.key in noCopyHeaders }
       .associate { it.toPair() }
maybe a useless optimization, but could be useful on big datasets
👍 1
s

StavFX

12/19/2019, 5:50 PM
I agree, since we’re going to call filter+associate either way, it’s probably better to filter first. On the matter of code style, I still prefer
.filter { it.key !in noCopyHeaders }
to
.filterNot { it.key in noCopyHeaders }
, just because it sounds more like English when read out loud, but that’s totally a matter of preference :)
1
m

Matteo Mirk

12/20/2019, 9:38 AM
Good point about filtering, yes. Oh I see your preference, yeah it’s a matter of preference, I liked to use this
filterNot()
since it’s available in Kotlin, but I can see maybe doesn’t read very well. On a side note, I remember there was some IntelliJ inspection warning to not negate your condition in an if/else to ease reasoning, what do you think?
s

StavFX

12/20/2019, 7:05 PM
In a lot of cases I would agree. e.g.
if (shouldKeep(item))
is better than
if (!shouldDiscard(item)
. But honestly I find that
filter
is already “confusing” because I have seen that for a lot of developers encountering
filter()
for the first time, they think about it as “should I filter (out) this item?“, rather than what it actually is, which is “should I keep this item?” So we have to “learn” that
filter
will KEEP anything I respond
true
to (and I personally have to repeat that to myself once in a while when trying to figure out what my predicate should return, but maybe I should already know this “intuitively” 😝). Anyway, that long rant about
filter
was to say that
filterNot
adds another layer of cognitive load (for me) where I have to think “ok, so filter keeps whatever I return true for, so filterNot will keep the falses”. Again, this is all a matter of preference, because if you naturally think of filter as “should I keep this item?” - then maybe
filterNot
makes more sense to you. To me it’s still confusing because now the question becomes “should I not keep this?“. How do you think about
filter
and
filterNot
? Maybe it’ll help me get more comfortable with it 😅
m

Matteo Mirk

12/23/2019, 9:22 AM
You’re absolutely right, I can relate because I still get confused by
filter
semantics, both in Java and Kotlin, and need to look up the docs at least once per session! 😄 I understand this double confusion about the negated filter: they added very useful extensions in Kotlin, but maybe
filterNot
is more confusing that helpful.