@jhoffner: I've added a comment to my solution with a version implementing the more sophisticated version you were talking about.

It doesn't make it significantly more difficult, and from what I can tell it just makes the code more unwieldy by requiring more special cases to be checked for. So, I guess what I'm saying is: This kata can stay as it is, as far as I'm concerned.

me 2

The kata is http://www.codewars.com/dojo/katas/52ae2db783f47875d0000064 It's all in comments what is wrong with it.

I agree about small/large fixes approach. Such things would be nice. Also few things you may want to consider:

• moderator before moving kata out of the beta, should (could?) read all the comments and make sure there are no open issues - if this would not be too much to ask? Usually there are not so many comments, but still it could take some time...
  
• some "ping moderator" button, if author does not react to the issue comments, but kata is already out of beta.
  
• possibility to indicate issues even if kata is out of beta?

But maybe my suggested things won't be needed, if you implement such nice workflow like jhoffner described two comments below this ;] in such scenario moderator just could check if all the issues were fixed and then approve it

I know one thing, moving kata out of the beta based only on upvote count is not entirely the best way to do that. You may want to combine this with that marking/fixing issue scenario.

Thats a good point, right now the best way is to manually comment it or email us... which kata was the problem on?

We're in the process of building a smart way of fixing and editing kata that pulls kata back to beta when necessary. The idea is you can patch a kata (small fixes, typos, text, tags) which directly edits the live version. Though larger fixes like major issues or translation to another language would send it back into beta. Thoughts?

Yeah, that sometimes fails. I just saw one example: kata had major issue vote, it reached 10 upvotes and was moved out of beta, but the issue/bug was not fixed. Is there some mechanism to report such katas to moderators? Are you planning to implement some workflow for moving kata back to beta in the future?

Just saw this. Once a kata has 5 ready votes (and no issues reported) than it comes out of beta. If any issues are reported, than 10 ready votes are needed.

I'm still getting:
Test Failed: solution(1,2,3,10,5) was supposed to return 1,2,3,5,10 (using CoffeeScript)

Arlaneenalra, Sorry I hadn't had a chacne to review your code. If you post it again, I can check it out. Just put it up here and mark the comment as spoiler content.

Wow! I would love to see what you got this far. Maybe I could give some pointers.

I had a similar problem when working on the "Simple Time Bomb" kata. This was useful in clarifying the details. Basically each scope (i.e. 'context') has an Activation object that tracks all of the local variables, such as 'arguments' and 'this' and anything else that is declared with var statements. This activation object cannot be directly accessed through javascript itself, so it is impossible to iterate over the properties - you can only use properties that you know the names for (such as 'this' and 'arguments'.)

Also, this is helpful.

And here is the actual definition that explicitely states that direct access to the list is impossible.

check out neurotrace's solution. It is pretty slick.

I've updated the test cases to use the new describe/it format, so now figuring out what is expected should be a lot more clear. I've also updated the description to indicate that array values do not need to be handled.

However I can see how this kata could have been made more sophisticated by allowing something like this:

builder.params.b = [1,2]
builder.mode = 'legacy'
builder.build() // returns ...?b=1&b=2