i'm doing multimaps without Guava and wanting a way to merge two

Map<K, List<V>>

instances by appending lists

Wonder if you could also fold the case where you want to combine two maps but if a key is present in the first map, then its value should be taken

@jw: I would probably generalise it with

map.update { k,v -> v }

function. Thinking out loud as well.

so your case would be just

map1.update { k,v -> v + map2[k] ?: emptyList() }

or something

That only works for keys in map1 and doesn't cover keys only in map2.

I forgot to experiment. I just wrote the boring imperative version and moved on

I know Kotlin's

Iterable.map

is eager and for lazy

map

we have sequences but what if I truly need a transformed view of a list with random access? Guava's

Lists.transform

does just that but I'm trying to get rid of Guava.

@kirillrakhman: I believe you have to cook your own

List

implementation.

note, that it would have to call transform function on every access, and if it’s an expensive function, you might need some caching, etc. That’s why it’s not in stdlib.

I understand that. Though, Guava doesn't cache anything either.

Also, lambda will be captured in this instance, and if it references something from scope, there is potential of a memory leak.

It also doesn’t generalise well for

filter

or other operators with unknown size/index of a resulting collection

Well, the capturing argument applies to every non-inlined method in the stdlib that uses lambdas (e.g. some compare methods aren't inlined) and the size is still known.

Another potential issue is an exception from transform function, which will occur on access.

Nope, eager functions run lambdas without leaving caller’s stack frame, so when function exists, nothing is being held anymore. For sequences, of course, it is all applicable, and that’s one of the reason to separate “simple and safe” usecase, from “lazy and potentially complex” one

Alright

maybe I'll just transform the list when it changes instead

Why not just inherit

AbstractList

and implement delegation with mapping? Shouldn’t be a lot of effort.

hm, that looks ok, indeed

I just noticed the irony of

AbstractList

throwing exceptions on all mutating operations

it's almost as if

List

never was intended to be mutable by default

Yeah. I really like Kotlin’s separate Mutable / Immutable interfaces for collections. The argument for why this wasn’t done in the original design of Java collections always felt a bit weak to me

yeah, they argue it's too hard/too complex/too many types, but Kotlin shows that this wasn't really a big deal. Perhaps one day they'll revisit the collections library and refactor it a bit

The Java SDK in general tends to show a poor understanding of stable, reusable OO design. And then, due to the backwards compatibility charade, they lock themselves into the most delightful decisions. Would be nice to have an alternative JDK...

@fellshard: Cane to elaborate about the "poor understanding" part?

Lack of encapsulation, primarily, and lack of extensibility. If a piece of the SDK is unsuitable for your needs, how easy is it to craft a custom component to fit in its place? How many external or excess concerns do you have to worry yourself with in order to accomplish that? Take, for example, the

List

interface of Java's collections. How simple is it to create your own implementation? What kind of constraints are placed on the general concept of a list that are unnecessary at that level of detail? As an SDK construct, one would expect small, composable interfaces to enable usage of parts of functionality in different contexts, but the SDK encourages depending on vast swathes of functionality simultaneously with its bloated implementations. To be fair, I have a hard time gauging what exactly causes that inflexibility. Could be an overreliance on inheritance over composition, but I'm not sure. It's easily seen in the collections, as others have noted. Just take the SOLID principles, start wading through the SDK, and marvel at how incoherent the structure can be. Standard does not mean good. It means just that - standard, the foundation that everyone shares. Much like Java itself, it's used because everyone uses it, not because it is of high quality.

Contrast the SDK of, say, Kotlin. Or Scala, to some extent. Specifically Scala's beautiful collections mentality (even if it does fall a little deep down the type rabbit hole)

Scala's beautiful collections? Are we looking at the same ones?

CanBuildFrom

and all?

Yup 😛

The primary part that's interesting is their specific separation of mutability and immutability, as well as decomposition of functionality (Traversable, Sequence, Iterable, etc.) and simple derivation of a host of operations from a set of basic atomic functions. A lot of that seems to stem from Scala's use of mix-ins and traits. Not perfect, but it shows what a more thorough mentality can bring to the table.