String is final so it's not like you can pass the equivalent of a lazily evaluated version

I guess it would in fact act as if it was a lambda. just a syntax sugar and probably not that good of an idea, just something that came to mind

I'm thinking to make a kotlin adapter for guava. can you guys throw me some names for it?

Kuava obviously.

which is apparently Tongan for guava. I don't know what I expected

Guava is mostly adapters for parts of the JDK that are missing or need filling in.

I believe Kotlin already addresses many of the same points, or requires a new set of adaptations instead of relying on those Guava used.

collections aren't covered at all

at the very least

kotlin has tons of collections helpers

^

i occasionally miss a BiMap and MultiMap every now an then, but extension functions on normal maps can easily get you close enough

There's definitely bits of Guava to adapt, to be sure! Just not all of it. Be selective. 🙂

Multimaps are pretty much available readily in Kotlin. Things from Guava that are still relevant in Kotlin would be

LoadingCache

, but even then, not much you can do besides adding some thin syntactic wrapper

i wouldn't even consider loading cache a collection utility

it's less fundamental

looks like their package choice agrees too

I also don't really see how bimap can be implemented by extensions on normal maps, unless you create new setters that always guarantee that values are unique

guava has some really nice features, but i find myself using it less and less with java 8 and kotlin

the caching stuff is probably the thing i would use most, although some of the string manipulation stuff is nice too

in any case, even if a good half of it isn't needed, it still has a lot of features that could use better syntax for usage in Kotlin

that's probably true

@cypher121: the listenable future stuff would be a good place to do that. there's the

Futures

utility class that would be a good thing to switch to extension methods

the hashing stuff as extensions on strings would probably be nice too

Can_somebody_take_a_look_at_this_and_explain_the_behavior_that_I___m_seeing__Is_that_a_language_bug_.kt

The behavior in Snippet 1 (setter not called) is counter-intuitive but ok, I can understand that maybe that’s how the language works. Snippet 2, I just can’t understand the logic. Snippet 3 blows my mind. Snippet 4 is logical but makes the behavior of Snippet 2 and 3 even harder to understand.

init vs. constructor is your problem, I think. With the explicit constructor in 3, a is probably given the value 0 first

In 2, it's not provided in any constructor, and no explicit default constructor is made, so it's never intialized. Init is not part of initial object creation, but rather runs directly after, iirc

Snippet 1: better to have a way to have default values without passing through setter than to have no mechanism to do so

Odd at your note in 3 that it has to be a separate constructor, though... hmmm