I don’t see it at all but what about nesting relat...
# getting-started
m
I don’t see it at all but what about nesting related functions? instead of having a lot private functions that are called from only one place those functions can be nested inside function that actually need them. make them lambdas also works… what are your thought/experiences?
j
I don't see any real benefit in it, but I see lots of drawbacks. The main benefit would be to reduce the visibility of the function: instead of file scope, it would be only visible in the outer function. However, this benefit seems minimal if you keep your files at a decent size: the difference in scope should be small in that case. Now the drawbacks: 1. One obvious drawback that bothers me is the actual nesting. If you really follow this approach, you get several levels of indentation and at some point it becomes hard to read. 2. You are mixing nested declarations and function body. It makes the actual body of the outer function harder to read IMO. I prefer to see a function with all its body at a given level of abstraction, and then other private functions below with lower levels of abstraction. 3. Yet another point is that if you need to reuse a nested function at some point in some other place, you need to extract it from the initial outer function, which makes a very big change in the VCS and code review for a very little thing. Also, if you change anything in the nested function at the same time, it becomes very hard to notice this change during review. On the other hand, the standard approach means absolutely 0 change if a function needs to be reused in the same file, or a tiny visibility modifier change if you need to reuse it elsewhere (that is unless you actually need to make changes to the reused function of course). That being said, all of this really depends on the size of the thing we are talking about. I mostly have a problem with using this approach extensively and recursively. Of course defining very small functions without any nested functions themselves would be totally acceptable and useful. In that case I would usually go for lambdas. It would be nice to have examples, because it's hard to discuss this in the general sense.
k
I agree with Joffrey about the drawbacks of deeply nested functions, but I think one big reason is that it's not idiomatic in Kotlin due to historical reasons. When structured languages first appeared, at least the mainstream ones - Algol, Algol-68, Pascal - all supported nested functions, and it was not uncommon to use that feature. Then came C. It brought with it certain new abilities, but due to its design for simplicity it also lost some features, function nesting being one of them. And many new languages followed in the 1990s (C++, C# and Java) that were based on C and also didn't support function nesting. Kotlin supports it, but presumably because most Kotlin developers learn Java first, it hasn't caught on. On the other hand, you'll see nested functions being used in other languages, especially functional languages like Haskell. As for using them in Kotlin, I would be happy to see small nested functions (let's say, a maximum of 3-4 lines), especially when the nature of the function is such that it only makes sense in the context of its parent function. Note also that nested functions allow the use of their parent function's local variables and arguments, something you can't do with a non-nested function unless you explicitly pass them.
👍 1
j
Note also that nested functions allow the use of their parent function's local variables and arguments, something you can't do with a non-nested function unless you explicitly pass them.
This is precisely the only reason that made me need a nested function, but it only happened once so far. And honestly if the enclosing function is big enough so that you need smaller functions to operate on its local variables, you should usually instead create a class to hold that local state and methods to operate on it
s
I do use nested functions now and then. I like how it keeps me from "poluting" the rest of the class.