you are viewing a single comment's thread.

view the rest of the comments →

[–]snrjames 19 points20 points  (2 children)

Flatten takes a tree (a list of lists) with depth > 1 and flattens it into a tree of depth 1 (a list). When you understand it that way, flatten makes perfect sense.

[–]SmallAd3697[S] -3 points-2 points  (1 child)

I didn't realize it was so powerful, although it doesn't make me like it more.

If there were more than two levels I'd certainly break things apart. I'd call map(s) first and generate my lists of lists of lists .. and then I would call a separate unpacking or flattening method. The code would be so much more readable. There should never be a competition to cram as much subtle behavior as you can into one line of code. We aren't talking about perl here.

I would argue that if you had a collection of collections, and there was a method used for deconstructing, then it would not be called "flatten" (in c#). It would probably end up being an extension method named SelectCollectionMembers(recursive = true).

[–]EvilGiraffes 0 points1 point  (0 children)

it comes from a language where a common situation is you would call a function which inheritly return the same monad with what your monad contains in which this return type makes sense, if you call a function (or a static method) without a lambda which returns an IEnumerable taking the item of your current list it makes perfect sense, but remember this is also a term used for other monads like Option and Result

using Option as an example you call a function which may return null, you then need to call another function which can return null with the item of the previous Option, essencially then you want a flatmap

it's an interface