Hello. Do you have any nice examples of how to use...

# server

[João Paulo Gomes]

Hello. Do you have any nice examples of how to use the new Kotlin Explicit backing fields in a non-Android code?

[Anonymike]

Wow, I'm glad you mentioned this as I completely missed this feature and could use it heavily as we have a lot of Flows and other classes that everytime we use them we only want to expose immutable versions of them.

After you comment I tried the code here in some server code:
https://noob-programmer.medium.com/kotlins-explicit-backing-fields-a-cleaner-way-to-work-with-mutablestateflow-926e2dbc946e

I ended up with this compiler error and I haven't yet seen a way to opt-in to the new functionality in the KEEP or anywhere I've searched yet, but I'll be looking too!

[simon.vergauwen]

It's only useful for mutation, that needs to be encapsulated in a class. It's a really uncommon pattern on server-side afaik.

It's typically used for listening to atomic state, where atomic state is represented SharedFlow<A> instead of AtomicReference<A>. To the outside world you want to only show SharedFlow<A>.

But internal in your class, you need to be able to update its state. Which you can using MutableSharedFlow<A> to update the value inside using update { prev -> calculateNew(prev) } and set(value) just like you would on an AtomicReference.

Where:

interface MutableSharedFlow<A> : SharedFlow<A> {
  fun update(block: (A) -> A)
  fun set(value: A)
}

So inside of your class you can now define that in a single step.

val state: SharedFlow<A>
  field: MutableShareFlow(...)

Again, this is a really uncommon pattern on servers-side. Only if you're building mutable state machines this might be useful, which is what everyone on Android is doing.

[simon.vergauwen]

Wow, I'm glad you mentioned this as I completely missed this feature and could use it heavily as we have a lot of Flows and other classes that everytime we use them we only want to expose immutable versions of them.

Are you using this on the server? 🤯 What kind of use-cases? I am assuming not for simple request<->response.

[Anonymike]

We have a lot of micro frameworks for high performance concurrency, etc. Similar to the way you might use a connection pool like Hikari CP for high-performance database connection management and reuse, we do the same for many services that are CPU, disk or network intensive. In memory stats are a great example where MutableState specifically is useful.

The example I just tried to test with is a model for managing and listening to jobs in a machine learning scenario, but we would absolutely use something like this in email service code as well where we have several of this exact scenario. Obviously this syntax is more of a convenience that we probably wouldn't go back and refactor for no reason having already written the longer form of the code, but this would be helpful going forward to make it obvious and get rid of a lot of underscore and intermediate properties (if it works as I think I understand it).

[Anonymike]

To be clear, yes, the majority of our code is server-side for web applications, etc. I think its funny that most of the concurrency stuff we see these days is viewed from the context of a mobile app where only one user is likely doing something at one time and hanging UI is the biggest worry. Concurrency and memory management takes on a whole other meaning when its millions of users pounding the same instance of an application on the server haha.

[simon.vergauwen]

Thanks for sharing @Anonymike!

Aha, I was thinking of pooling as a scenario ☺️ Totally makes sense in such scenario's, but not what I see on average in a server-side project.

I love streaming, and concurrency for millions of users, wish I could be like a fly on the wall in your codebase 😁

[Anonymike]

Haha, happy to share. I started web dev in a language that is generally not appreciated by computer science folks, but very powerful (CFML). CFML's creators (Allaire / Allaire brothers) were big innovators in early web applications. Cfml was a tag and function syntax like html designed only for building web apps, with many scopes for memory lifecycle (Server, Application, Session, Request, Url, Form, etc) and an application server that simplified common needs in tags like cfmail and cfquery. We constantly had to explain why it wasn't a toy because it didn't look like the C/Java scripting syntaxes we were all used to. It made us think very differently about the server side, templating, and especially memory management. It was hilarious getting told it was a toy by others when we were literally building websites for superbowl football teams back then, but a great lesson for younger developers about respecting everything and following provable results/productivity. We moved to Kotlin when we could take the combination of things we learned and bridge the gap that we felt cfml did really well with the benefits of Kotlin, so we have a similar set of scoping mechanisms and a simple MVC architecture that allows us to provide clean, isolated, thread-safe services that are easy to use at the request level.

TLDR version is we use a lot more simple singleton patterns and such than we see in most other code bases and just set things up to be easy to use while reducing per-request memory churn. Happy to share more sometime and would always love to hear any perspectives on others' server-side architecture as well @simon.vergauwen And if you ever want to nerd out on databases and query optimization, I'm quite possibly the one person that will get giggly excited about that haha.

[CLOVIS]

If you ever get into nerding about databases & query optimizations, please count me in!

[Jacob]

Cfml. Is that another name for cold fusion?

[Jacob]

This is triggering my PTSD from my cold fusion days.

[Anonymike]

Haha, yes...common experience for many folks was:
1. Business people who just wanted to get something done wrote horrible code.
2. Developers who wanted to build something either got scared away by business people code or ran from it before learning from it.

[Anonymike]

It sat in an interesting place at an interesting time for sure. Nowadays, there is an open source implementation called Lucee and its typically referred to as CFML rather than the trademark name "ColdFusion".

[Anonymike]

@João Paulo Gomes Sorry for derailing the thread. Happy to continue off topic conversation directly or another thread with anyone of course. I'll certainly come back here if I figure out how to test out the explicity backing fields.

[Anonymike]

More to the original conversation, I just found this and confirmed it works in server code. I didn't do much else other than prove it compiles and my project still ran though.

Gradle change to enable the experimental feature:

kotlin {
    sourceSets.all {
        languageSettings.enableLanguageFeature("ExplicitBackingFields")
    }
}

https://stackoverflow.com/questions/78529749/explicit-backing-field-not-working-in-latest-kotlin-2-0-0-android