Any opinion on prefixing

Flow<Boolean>

with "is". E.g.

val isVisible: Flow<Boolean>

?

I would follow the same convention as for a regular Boolean property. In my experience Kotlin uses the

is

prefix for those, though I can’t find a mention in the official style guide…

Kotlin property naming generally follows JavaBeans conventions, http://www.oracle.com/technetwork/java/javase/documentation/spec-136004.html

So what would you suggest instead?

I think the main reason in Kotlin is used

isBoolean()

over

isBoolean

are contracts, when contracts are supported on getters and not only functions, probably all will be moved to getters instead of normal functions

Kotlin will still generate `isVisible()`/`setFoo()`, so it's not as confusing to Java consumers as `getIsFoo()`/`setIsFoo()` would be… but what name would be better would depend on context

Additionally, if you move to "reactive" like elements like compose or flow with molecule, where the

Flow

box disappears, they use

isVisible

too

visibilities.collect { isVisible -> }

reads better to me than

isVisible.collect { ??? -> }

@ephemient not sure about Java tho, I am thinking in Kotlin in general, I haven't consumed Kotlin from a Java project, maybe

@JvmName

can help there?

It's a series of visibility states. So plural makes sense.

I like the singular, because I would think of it as one value that changes over time, rather than a series of values. And I don’t like the Hungarian notation of e.g.

isVisibleStream

. The type already conveys that.

what if you have

Flow<List<Boolean>>

Curious: would

isVisible

be more palatable for a

StateFlow

than a plain old

Flow

?

In general, I agree with @Sam in that Hungarian notation is a bad idea and we should avoid repeating type information in names. If it were a

MutableState

, I'd name it

isVisible

. With flows, the plural makes sense to me, because it becomes a series of changes, and that's a different beast than a single value, even if it were a changing single value.

StateFlow<Boolean>

results in

isVisible.value

which I don't like, but it's less bad than the

Flow<Boolean>

scenario IMO

There is no difference between

MutableState

and

Flow

, or whatever

Flow

like box as it is a series of elements. Indeed with Molecule you get with

Flow

the same you have with

MutableState

MutableStateFlow

is a

Flow

of course, so in the cases where you're using it as a flow (and performing mapping operations on it or collecting it) then I would apply the

Flow

rules to it

Additionally, it is possible to use references too

visibilities.collect(MyComponent::show)

vs

isVisible.collect(MyComponent::show)

There is no difference between

MutableState

and

Flow

,

Then how would you iterate over a series of values with plain

MutableState

?

oh are we talking about Compose's MutableState and not Flow's MutableStateFlow now?

@ephemient I think he was meaning to the Compose

MutableState

which they do a trick as with Compose you "remove" the box, so it is a series of values but you write it like if it was only one

at least that's not what I read earlier… did I misread?

it looks weird to me too

that one makes total sense to me

in practice I think nobody does that, as an example with MVI could be

val state = store.state.collectAsState()

I just wanted to use another type expressing the same state, so just for the argument I chose

MutableState

. I'd name the base value and its mutable variant the same, so not Hungarian.

But I am not 100% sure, maybe

store.states.collectAsState()

exists, I haven't used it too much

I guess Kotlin authors would agree on singular form, because we have

FlowState

and not

FlowStates

?

no, what does that have to do with it?

val names: List<Name>

ups, makes sense. But since you just said it's a singular object, is it really ok to name it in multiple form? 🙂

yes. in real life, you call the Smith family, the Smiths. one singular family, multiple family members. ditto objects.

Personally, I'd name it

isVisibleFlow

or

isVisible

if it doesn't create name clashes and it doesn't end up being more confusing.