nice

Oh! You're right, i in people is not strictly the same mechanism as i < people.length. With our custom argument, people.length is undefined, so i < people.length will also always be false and the function will return 0.

There are so. many. ways. to walk a list in JS ..

I don't think all the freezeing is even necessary. If you're doing it for not being vulnerable to input modification by user, the better ( and simpler ) option is calling the reference solution first and saving the expected result. Unless your reference solution modifies its input ( which it really really should just not do, and if it absolutely has to you can pass it a copy ), that's less likely to bite you if you make a tiny mistake.

Re: developing kata as kumite - the best way to develop a kata is actually as a translation. That editor is even better - you can actually test your example tests! Unfortunately, the base language of a kata can never be in a translation. For any translated languages though, you can fork the translation, update it, approve that, and it'll overwrite the original translation. But doing it in a kumite is almost as good, as long as you don't need radically different example and submit tests.

Language specificity is not a problem.

You can develop your kata as a kumite. You can do the description, the solution, preloaded and the tests, then convert it to a kata and add an initial solution and example tests ( just copy over the submit tests and delete what you don't want. I usually have an exact copy of the example tests in the submit tests, under an it-header "example tests", anyway ).

As long as it's a kumite you, me and everybody who cares can fork it, solve it, shoot at it, improve the tests - but they don't get to downvote yet! :P

However, turning this into a kata - imagine what Alex ( FArekkusu ) is going to say. "A simple map/reduce/filter problem is not new." And he will be right. The testing will be new ( I've never seen this before! ), but the user task and the user solution will be just another simple map/reduce/filter my list kata. So no, I don't think it's a viable kata. I can't offhand think of a way to turn the testing into a kata either - that's the interesting part after all.

Besides, doing the interesting thing means you're forcing implementation instead of behaviour - that's not what a kata should be. People have tried again and again to make kata out of specific implementation requirements, and it seldom works.

That was fun to see develop! Relying on the fact that objects are not iterable is such an elegant solution, and removes the need to any kind of solution.txt checking.

Seems like a viable strategy for testing exclusive usage of map/filter/reduce and could easily extended to some/every/findIndex etc...

Is this the kind of problem that would be interesting to make a kata out of, or should this still stay as a kumite? I'm not sure what the community standards are for language-specific requirements to katas.

Confirmed that's the path now, and it works in kumite

Wwrong path. "/workspace/solution.txt". I thought I wrote that somewhere for you, but I can't find it now.

That's in kata - I hope it works in kumite also.

I couldn't get fs.readFileSync('/home/codewarrior/solution.txt', 'utf8'); working - it said there was no such file. Is that just in Kumite? Or was I doing that wrong?

Can we focus on one function at a time?

There should be multiple versions of it that should respectively pass and fail tests, and I get confused with multiple versions of multiple functions.

If you want people to use map, filter and reduce, specify that in the description.

There should be no need to give hints in tests. Lots of people don't read them anyway. They'll wake up only when they start actually failing tests. So fail them. Preferably with a good failure message, which in this case should probably come from the argument object. That's OK, we control that, so it can give appropriate messages when it's asked to do something we don't want it to do.

@JohanWiltink recommended potentially trying to do something with proxies if that's necessary. I think regexing for in solution.txt would probably be sufficient to point point people in the right direction.

This kata is dead and buried. You can't remove it more than it is ( there is no way to resurrect it either ), so just let it lie.

Awesome suggestion on the kumite - here it is: https://www.codewars.com/kumite/601d98152dc61400086240a9?sel=601d98152dc61400086240a9

I see that this kata is marked as "retired" - do I need to do anything else to remove it while we work on the kumite?