Suggestion: rename getXxxFlow() to observeXxx()

[xsveda]

There are some naming conventions for functions that manipulate with data on "repository" level. One of them I use the most:

• get()/set() - functions are synchronous
• load()/store() - functions are asynchronous (suspend when using coroutines)
• observe() - functions return observable item (Flow when using coroutines)

The advantage of this "language" is that it is transferable between technologies, so an Android dev using Coroutines or RxJava understands an iOS dev using RxSwift or Combine.

It is also prefered not to spell the return type of a function in its name, rather name it by its purpose.

So instead getStringFlow(), getStringOrNullFlow(), ..., I suggest naming the functions for observing data observeString(), observeStringOrNull(), ...

One disadvantage is that if the Multiplatform Setting lib would like to support other observable primitives (as return types), it wouldn't be easily distinguishable. On the other hand, there is a plethora of adapters for Flow to other asynchronous libraries so I don't see a use case for it for now.

[russhwolf]

Naming is hard. I'll think on this, but I also want to hear from more people that getXXXFlow() is awkward before I'm convinced it needs to change. Maybe worth comparing more to what other people are doing with Flow APIs.

For observeXXX() in particular, one issue is that it might get confused with ObservableSettings and addListener().

[westnordost]

To me, it would make most sense to name it similar to how it is named in other Kotlin APIs.

And it looks like other Kotlin APIs also call the Flow by its name, e.g. flowOf, receiveAsFlow asFlow, channelFlow etc. Maybe this is even some official naming convention? I notice Kotlin APIs in general are quite explicit in what they return.

So, a flow may be observable, but many other things are observable, too. To have Flow in the name seems to be the more clear name to me.

[russhwolf]

I'm not going to make any change here.

I agree that in application code, a more semantic name is better than one that's based on the return type. But I don't agree with that reasoning for a library like this. The purpose of the multiplatform-settings-coroutines module is to adapt the general observability mechanisms in multiplatform-settings to work with kotlinx.coroutines APIs. I don't see the purpose of abstracting away from coroutines-based naming in that context. If that naming doesn't fit for you at the application level, then you can use a different naming scheme in the data layer you write on top of Multiplatform Settings.