How to cache the kotlin way


Hello guys,

I’m starting to learn Kotlin (or rather wrap my head around its concepts).
While the more expressive syntax is a huge win compared to the more boilerplate-y java, I’m interested to really learn the Kotlin way of doing things.
And see really how much boilerplate code I can kill with Kotlin :slight_smile:

So right now, I’m comparing to other initiatives that tried to push java’s boundaries (playframework 1 with it’s byte code injection and AndroidAnnotations with apt processing being two I liked)

Anyway, my question is about the common caching pattern.

How would Kotlin help to cache that call:

List<DomainObject> findObjects( SomeType param1,  SomeOtherType param2)

The complicated part usually being generating the cache key from a concatenation of the method’s and parameter’s names.


Some kind of a built-in memoization mechanism could help maybe, btu we don't have such a thing in Kotlin (yet). Check out delegated properties, just in case:


Thanks for your clear anwser.

If you indulge me, I’ll go in a personal rant.
A rant about language design.
(I’m not sure this the right place. But hey, if you don’t like that post, you could always flag it).

But before beginning I want to say that I like Kotlin.
I like it a lot.
And there is no “but…”

Anyway, onto language design.

The thing is I don’t know about language design.

Which means I don’t care about language “purity” of vision.
(As long as the implementation of that vision makes sense.
Nobody wants another VB6 where eveything feels badly cobbled together)

Wich means that I don’t care about the simplicity of language core concepts (as the Scala creator argued)
While I understand that it could be satisfying to a language designer, I couldn’t care less as I’m not one of those.
And I also understand that languages are not all the same.
Some are aimed at the lowest common denominator.
Some are aimed at hobbyists.
Some are aimed at people that like to write unit tests and documentation to compensate for a type system.
All this is fine by me.

I have no issue with not being the target of some languages.
Or most of them.
I have no issue with new languages I don’t care about being popular and even sometimes kind of successful.
(And by that, I mean the virus’ definition of successful: being widespread.
Wwhich is the - sometimes unadmitted - goal of most programming languages).

And I have no issue that my pet peeves are not being at the center of language designers’ preoccupations.

I am keeping myself informed about the new sttuff and zero in on the language that could be a benefit to me.
I’m a pragmatist: being hip is not a benefit.
Also I’m not willing to pay more in hosting at the face value of some new ideas.
Also I’m not willing to write more lines (whatever the DSL is) at the face value of some new trend.

I want to write lines that are more expressive
And less of them.
(And I can’t be convinced that replacing a method by some convoluted punctuaction sign is brevirty.
Or expressiveness)

That’s the reason why I am naturally interested in language that says: here are the common code patterns that we want to make easier.
Let’s say for example: dependency injection, modularity, composition, reducing the use of external DSL/Markup
And focus on those patterns.
And came with language concepts that make sense in light of those goals.

I’m interested in that type of communication because it speaks to me: I can tell quickly if those patterns are the one I use.
The ones I feel that I write too much code around.
I can tell quickly if that language is for me.

The languages that lists a bunch of features or preach some paradigm (static/dynamic typing) out of the blue air don’t talk to me.
At least not directly.
Of couse, I know how to map closures, traits/multiple inheritance or other well known features to my everyday code patterns.
But there is one extra step needed here.
One level of indirection.

This is the end of my rant.

I just want to say that I like what you are doing here.
Having a conversation.
Showing code.
Showing how Kotlin could be relevant to my everyday code.