Hi everyone, curious about everyone’s preferred no...

# coroutines

[Tash]

Hi everyone, curious about everyone’s preferred nomenclature for methods returning Flow<T>
For example:

// For Flow<List<*>>
fun postsFlow(): Flow<List<Post>> 
// OR
fun postLists(): Flow<List<Post>>


// For Flow<*>
fun eventFlow(): Flow<Event>
// OR
fun events(): Flow<Event>

Would be interesting to know if there are other preferred styles.

[Ray Ryan]

I like the latter in both cases.

[Ray Ryan]

Just postList() for the first one, if it’s a property that changes on occasion.

[henrikhorbovyi]

second option for both \o/

[Orhan Tozan]

posts() and events()

[elizarov]

It might look even better as a property. Flows are cold, nothing happens when you “call” these functions, so there’s no need to write events(). Those () do not signify anything. Just writing events should do just as well.

[Tash]

Nice, makes sense that they can just be `val`s if no arguments are needed.

[Orhan Tozan]

@Tash just because not having arguments isnt a sufficient reason for going for a property over a method. If a method has side effects, you better keep it as a method, even if it requires no arguments

[Tash]

For sure, this is more about:

fun events() = flow<Event> {
   ...
}

VS

val events = flow<Event> {
   ...
}

And not about the case where events() causes side-effects etc.

[louiscad]

@Orhan Tozan If you use flow { } builder, there's not really any side effects, that's why it's perfectly safe to keep it in a property.