1

I'm asking myself what the language designers intention behind the also scope function was and if almost everyone is misusing it.

If you search here on stack overflow for examples of Kotlins scope functions, you'll end up with this accepted answer: https://stackoverflow.com/a/45977254/5122729

The given answer for also { } is

also - use it when you want to use apply, but don't want to shadow this

class FruitBasket { private var weight = 0

fun addFrom(appleTree: AppleTree) { val apple = appleTree.pick().also { apple -> this.weight += apple.weight add(apple) } ... } ... fun add(fruit: Fruit) = ... } 

Using apply here would shadow this, so that this.weight would refer to the apple, and not to the fruit basket.

That's also the usage I see quite often. But if I have a look into the documentation at kotlinlang.org, they are clearly saying:

also is good for performing some actions that take the context object as an argument. Use also for additional actions that don't alter the object, such as logging or printing debug information. Usually, you can remove the calls of also from the call chain without breaking the program logic.

From that point of view, the given example would be wrong as it would break the program logic if it is removed. For me, also is kind of Javas peek (doc), which is there, but should not be used for productive program logic.

Can someone enlighten me?

3
  • 1
    They're saying that if you are doing stuff with an object rather than doing something to it (configuring it), it makes more sense semantically to treat it as an argument rather than a receiver. The example above fits that idea perfectly. But the example is also a case where the code would be more concise and readable without the scope function. It would make sense to use it if the function also returned the apple and so you weren't assigning it to a val. Commented Apr 22, 2020 at 15:08
  • But what about the last sentence, that those calls can usually be removed without breaking the program logic? If I would remove the add call from the example, the result would not be the same anymore. Commented Apr 22, 2020 at 21:23
  • 1
    I see, i suppose it doesn’t fit that idea that it’s just for doing some logging on the side. The example above is kind of a pointless use of it, but could be helpful to shorten the code for a simple function that retrieves something, does something with it, and then returns it. But I guess with could be considered a more readable way of doing the same. I think the original intent of also is to log stuff in the middle of a chain of functional programming calls on a collection without interrupting it. Commented Apr 22, 2020 at 22:55

1 Answer 1

0

After having a longer discussion on Reddit about this topic, the documentation was adjusted in a way were the sentence

Usually, you can remove the calls of also from the call chain without breaking the program logic.

was removed. See the corresponding PR: https://github.com/JetBrains/kotlin-web-site/pull/1676

Sign up to request clarification or add additional context in comments.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.