https://kotlinlang.org logo
Join Slack
Powered by
Any opinion on prefixing `Flow<Boolean>` wit...
# naming
p
Any opinion on prefixing 
Flow<Boolean>
with "is". E.g. 
val isVisible: Flow<Boolean>
?
s
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…
e
Kotlin property naming generally follows JavaBeans conventions, http://www.oracle.com/technetwork/java/javase/documentation/spec-136004.html
Kotlin's
Copy code
var foo: Any
behaves like
Copy code
public Object getFoo();
public void setFoo(Object);
in Java
the JavaBeans specification explicitly allows
Copy code
public boolean isFoo();
to be a getter for the 
foo
property, only if the type is 
boolean
.
that does not apply to 
Flow<Boolean>
, so I would not name it 
isVisible
o
So what would you suggest instead?
j
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
e
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
??
I'm sorry, I can't parse what you wrote there.
j
Additionally, if you move to "reactive" like elements like compose or flow with molecule, where the 
Flow
box disappears, they use 
isVisible
too
I am not sure if it is a better name 
isVisibleStream
over 
isVisible
, I would stick without 
Stream
IMO
e
Copy code
visibilities.collect { isVisible -> }
reads better to me than
Copy code
isVisible.collect { ??? -> }
j
@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?
visibilities
looks weird for me, it is the state of an element, so it can look like there are visibilities for multiple components on the first sight
o
It's a series of visibility states. So plural makes sense.
s
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.
j
what if you have 
Flow<List<Boolean>>
that will be 
visibilities
for me
s
Curious: would 
isVisible
be more palatable for a 
StateFlow
than a plain old 
Flow
?
o
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.
e
StateFlow<Boolean>
results in 
isVisible.value
which I don't like, but it's less bad than the 
Flow<Boolean>
scenario IMO
j
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
e
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
simply getting the 
value
once is… eh, not that bad
j
Additionally, it is possible to use references too 
visibilities.collect(MyComponent::show)
vs 
isVisible.collect(MyComponent::show)
o
There is no difference between 
MutableState
and 
Flow
,
Then how would you iterate over a series of values with plain 
MutableState
?
e
oh are we talking about Compose's MutableState and not Flow's MutableStateFlow now?
that's not what the discussion was earlier, but ok
j
@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
val isVisible = visibilities.collectAsState()
e
at least that's not what I read earlier… did I misread?
j
it looks weird to me too
e
that one makes total sense to me
you're pulling a snapshot out of the all the visibilities over time
j
in practice I think nobody does that, as an example with MVI could be 
val state = store.state.collectAsState()
o
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.
j
But I am not 100% sure, maybe 
store.states.collectAsState()
exists, I haven't used it too much
additionally, in the store what would we have for the private part? 
_states
? or 
_state
? 
_states.value = ...
vs 
_state.value = ...
and when they improve the part in which we don't need the private property, we would use 
states
or 
state
so the consumer and the producer will use the same one
p
I guess Kotlin authors would agree on singular form, because we have 
FlowState
and not 
FlowStates
?
e
no, what does that have to do with it?
Copy code
val names: List<Name>
a list is a singular collection containing multiple items, a flow is a singular object emitting multiple items
p
ups, makes sense. But since you just said it's a singular object, is it really ok to name it in multiple form? 🙂
e
yes. in real life, you call the Smith family, the Smiths. one singular family, multiple family members. ditto objects.
l
Personally, I'd name it 
isVisibleFlow
or 
isVisible
if it doesn't create name clashes and it doesn't end up being more confusing.
8 Views
Open in Slack
PreviousNext
Powered by