!

I agree that Hash resulting from a proper solution to this kata would be an obscenity in production code, but I would still suggest people try to solve the kata in order to see how well they understand ruby. I tried, failed, and learned some things in the process (My thanks to @ineiti).

And the usage of class variables. I'd say that's the most off.

Thanks for your reply - I changed the wording from "static method" to "class method", because I know I'm awfully bad at chosing the correct terms :(

I think it's very important to have a common guideline for the Katas, do you mind if we continue the discussion about what should be done / not done at

http://www.codewars.com/topics/kata-best-practices

??

Thanks for your example - it's nearly more clear. Do I understand correctly that grandchildren won't be taken in your example, but that they would when using "inherited"?

Thanks for your propositions - I changed some of it, and added an example in the description.

I think it has been proposed already to have a "best practices" for each language, like whether to put spaces around arguments, putting {} or do...end, or such. Everybody's used to some style, so is it better to promote different styles, or is it better to make it all look the same?

I couldn't find your solution, I was eager to see how you did it! Is it my slow connection that doesn't show all solutions?

Thats fair enough. To be honest I don't remember my thought process at the time for making the functionality accept variable inputs. I may have been trying to actually require the user to know the ins and outs of how JavaScript handles arguments, as this is a very important thing to know - however it does fragment the spirit of the kata a bit (is it about handling arguments or about recursion).

At a personal level I tend to prefer methods to allow variable inputs. Especially if I see myself possibly having to wrap them in an array just to fit the method signature properly. A flatten method like this could be used to flatten multiple sources into one. Some would probably argue that wrapping multiple inputs into a single input would make the code more clear and I can see that. In this case, the method usage is actually flexible to do either or. If you want to flatten a single array just pass in a single array.

The flatten() method probably isn't a useful utility method that you would ever actually want to use but the general idea of having to extract data and transform it into a different format is obviously something that is done often. This is a basic exercise to practice that concept. More advanced and real-world use kata that expand on this concept will no doubt be created in the future.

Its a good point. I knew nothing of combinators but it seems to me like you are right about what pattern this is, based off of this information: http://www.haskell.org/haskellwiki/Combinator and http://en.wikipedia.org/wiki/Combinatory_logic.

Was too late in the evening. In fact, the Kata is RPN, what you want is more mathematical. But I still prefer the Kata-syntax :)

I bet you prefer RPN, reverse polish notation - you still have these old calculators around? Were they HP, I think?