James Richardson
12/11/2019, 2:19 PMSimon Kågedal Reimer
12/11/2019, 5:51 PM.first
!StavFX
12/11/2019, 6:50 PMMap.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 }
Simon Kågedal Reimer
12/11/2019, 6:57 PMMatteo Mirk
12/19/2019, 11:50 AMheaders.filterNot { it.key in noCopyHeaders }
.associate { it.toPair() }
maybe a useless optimization, but could be useful on big datasetsStavFX
12/19/2019, 5:50 PM.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 :)Matteo Mirk
12/20/2019, 9:38 AMfilterNot()
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?StavFX
12/20/2019, 7:05 PMif (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 😅Matteo Mirk
12/23/2019, 9:22 AMfilter
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.