Hi folks! Is there a functional way to write this? ```for (handler in handlers) { if (handler.ha...

# announcements

[iex]

Hi folks! Is there a functional way to write this?

for (handler in handlers) {
    if (handler.handle(uri)) break
}

[spand]

handlers.any { it.handle(uri) } maybe?

[spand]

But mixing functional style with sideeffects is a bit nasty

[Dico]

.find {} would also work

[Dico]

I agree with Johannes though

[streetsofboston]

Maybe

handlers.takeWhile { !it.handle(uri) }

[streetsofboston]

Or, if it is all side-effect related:

handlers.forEach { 
    if (it.handle(uri)) return@outerScope 
}

[spand]

I would prefer the break version to the last one ;-)

[spand]

In general I dont understand why people go to such lengths to avoid a simple for loop

[spand]

The style guide even mentions this https://kotlinlang.org/docs/reference/coding-conventions.html#using-loops

[iex]

yeah, break version seems actually better 🙂

[iex]

I should have added functional way that makes sense 😉 agree that functional for the sake of it is not good!

[Bob Glamm]

In general I dont understand why people go to such lengths to avoid a simple for loop

Answer #1: which is easier to read? The for loop or handlers.find { it.handle(uri) } ?

Answer #2: Assuming handlers have side-effects, then lurking under that for loop is the possibility of an unlimited number of side-effects. So instead of being able to look at just the for loop to determine where an error lies the entire application may need to be deconstructed to find it.

With those unconstrained effects comes an inability to usefully and completely test the code in question since there are now no rules about what can actually happen in that for loop. Unit and integration testing likely cannot cover all possible side-effects.

Writing the code as a tail-recursive find in an effect management system (such as Arrow) constrains the side-effects to be well-defined, proven correct-by-construction by the compiler, and requires only property-based tests to test - specifically, the property that at most a single handler is run.

[iex]

but in this case find isn't semantically correct

[iex]

and it doesn't help with the side effects as it's performing them anyway?

[Casey Brooks]

In a pure-functional language, the compiler does impose certain constraints about side-effects. But Kotlin is not pure-functional, and as such there is nothing inherently “safer” about using .find as-opposed to a for-loop. You can cause the exact same kinds of side effects in both, but in the .find case it’s harder to even know that side-effects are happening. With a for-loop, running code and breaking in the middle is much more obvious what’s going on. In the find case, it kind-of looks like the values have been precomputed, when in reality its computing them right there with the possibility of causing side-effects