https://kotlinlang.org logo
#naming
Title
# naming
p

Peter Mandeljc

02/07/2023, 10:23 AM
Any opinion on prefixing
Flow<Boolean>
with "is". E.g.
val isVisible: Flow<Boolean>
?
s

Sam

02/07/2023, 10:34 AM
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

ephemient

02/07/2023, 10:50 AM
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

Oliver.O

02/07/2023, 10:55 AM
So what would you suggest instead?
j

Javier

02/07/2023, 10:56 AM
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

ephemient

02/07/2023, 10:57 AM
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

Javier

02/07/2023, 10:58 AM
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

ephemient

02/07/2023, 11:00 AM
Copy code
visibilities.collect { isVisible -> }
reads better to me than
Copy code
isVisible.collect { ??? -> }
j

Javier

02/07/2023, 11:00 AM
@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

Oliver.O

02/07/2023, 11:02 AM
It's a series of visibility states. So plural makes sense.
s

Sam

02/07/2023, 11:04 AM
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

Javier

02/07/2023, 11:05 AM
what if you have
Flow<List<Boolean>>
that will be
visibilities
for me
s

Sam

02/07/2023, 11:15 AM
Curious: would
isVisible
be more palatable for a
StateFlow
than a plain old
Flow
?
o

Oliver.O

02/07/2023, 11:17 AM
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

ephemient

02/07/2023, 11:23 AM
StateFlow<Boolean>
results in
isVisible.value
which I don't like, but it's less bad than the
Flow<Boolean>
scenario IMO
j

Javier

02/07/2023, 11:23 AM
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

ephemient

02/07/2023, 11:24 AM
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

Javier

02/07/2023, 11:25 AM
Additionally, it is possible to use references too
visibilities.collect(MyComponent::show)
vs
isVisible.collect(MyComponent::show)
o

Oliver.O

02/07/2023, 11:26 AM
There is no difference between
MutableState
and
Flow
,
Then how would you iterate over a series of values with plain
MutableState
?
e

ephemient

02/07/2023, 11:26 AM
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

Javier

02/07/2023, 11:27 AM
@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

ephemient

02/07/2023, 11:27 AM
at least that's not what I read earlier… did I misread?
j

Javier

02/07/2023, 11:28 AM
it looks weird to me too
e

ephemient

02/07/2023, 11:28 AM
that one makes total sense to me
you're pulling a snapshot out of the all the visibilities over time
j

Javier

02/07/2023, 11:29 AM
in practice I think nobody does that, as an example with MVI could be
val state = store.state.collectAsState()
o

Oliver.O

02/07/2023, 11:29 AM
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

Javier

02/07/2023, 11:29 AM
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

Peter Mandeljc

02/07/2023, 11:41 AM
I guess Kotlin authors would agree on singular form, because we have
FlowState
and not
FlowStates
?
e

ephemient

02/07/2023, 11:42 AM
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

Peter Mandeljc

02/07/2023, 11:53 AM
ups, makes sense. But since you just said it's a singular object, is it really ok to name it in multiple form? 🙂
e

ephemient

02/07/2023, 11:55 AM
yes. in real life, you call the Smith family, the Smiths. one singular family, multiple family members. ditto objects.
l

louiscad

02/11/2023, 6:43 PM
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