Except, the details of the kata lie to you. There are additional tests which check for side effects(?) which I couldn't pass them just because I've checked hash as (!cache[hash]) instead of (cache in hash).

The additional tests are no longer additional, and the description is no longer incorrect in the description of the number and datatype of possible function arguments. Also, don't use flawed logic. :P

I'm not explaining "side effects"; you can ( now ) read the test and you can Google it ( Wikipedia has a useful article ).

The side effect test, of course, is the test against ! cache[hash] instead of hash in cache. But I won't be suggesting that in the error message.

Solved?

! cache[hash] may not do what you think it does if a function value is falsy

That was indeed the problem with your code BTW. I would have expected that problem to surface earlier in testing already, but it didn't. I may write some tests particularly for that bug, apart from moving the side effect test up and copying it to the example tests. I've written some memoisation code over the years that suffered from the same bug; it should be caught explicitly.

I can't work with that fork. Did you publish it? Or just save it?

Have you tried logging only if fn.length===0 ?

Answers to lots of kata can be googled of course. If I invented something truly unique, I wouldn't be making a kata out of it, I'd be writing a paper or getting a patent. :P

Difficulty on here is odd sometimes, I'll give you that. But it often depends on prior knowledge also: if you already know the solution, the problem seems a lot easier. I wrote the solutions years before I created the kata and wrote all the testing. Difficulty is set by everybody but the author BTW, but most everybody that solved the kata of course also already knew memoisation.

Could you fork your solution, change it to your not-working solution, and publish that, failed tests and all, so I can see what was actually happening to you? Please?

a) did throw me off, but only a little; I suspected as much, but I couldn't be sure.

b) "single" is intended as opposed to "more than one" earlier. I could rephrase that as "every argument, singly" ? You're not supposed to do things in a loop; you're supposed to memoise independently for every argument, one at a time. I'm also open for other suggestions to improve the description ( preferably no less concise than it is now though ).

c) last test section actually breaks the description. ( sorry 'bout that! :o ) It effectively passes you undefined ( this is normal JavaScript semantics, and I consider that to be expected ), which is not a Number, String or Object. Having to accept Object means you have to be flexible anyway. I'm thinking to change it to something less defined, which would include undefined. Again, open to suggestions.

d) the last test will always have that problem of course, and submit testing will also always have that problem. You could maybe have logged only for function.length===0, if you knew the last test was unique in that way, but that's not a general solution. It's, however, not intended as a surprise, so I could include it in the example tests ( that's an honest thing to do anyway ). Also, having that particular test be covered by the description should help ( a bit ). But whatever is the last test will always be difficult to debug. Hmmm .. should at least be the umpteenth test of the same kind then, not any kind of new test. Simply reordering the current tests may also help.

e) the kata asks for a generalised implementation of memoisation. That is of course easier to do if you have some experience with specific use cases of it, and can abstract and generalise from there. Kata also assumes some knowledge of functional programming, where "side effect" is ( or should be ) a well-know concept, entirely separate from memoisation. It's not "at least once" BTW; it's "exactly once".

f) I am unconvinced that you, with your limited experience, being unable to solve the kata means it has flaws. No offense. There are flaws, definitely, but if this were easy, it would have been 8 kyu and the description would have been a oneliner. Some background knowledge is assumed implicitly, and that could and maybe should be made explicit, but the other extreme is spelling out what you have to do to the point where there's no challenge at all. This kata is not intended to be ( and I don't think it presents itself as ) an introduction to memoisation ( that would be "memoise this particular function". there's other kata that do that. I could probably find some if you want ), so I don't think it should be held to that standard.

Memoisation itself does ( should, must ) not have side effects; it can ( does ) affect the side effects of its argument function. "Side effects" appears on the Wikipedia page of "pure function". ( Recommended reading! I think functional, pure programming is fun, and educational. )

OK, so: what should I do about that "single" in the description? what should I do about that last test? ( I can change it to (x) => v++, but that feels a bit like cheating. ) I definitely should move that to earlier in the submit tests, and copy it to the example tests, I think. and the big question: what is the intended audience for this kata, are you in it, and how much should I accomodate you? quite willing to do that, just unsure of how much is appropriate. ( and you may actually not be the best person to ask that question of. what to do, what to do? )

Couple final things: I did not set the difficulty for this kata, and the set difficulty of 6 kyu does not mean every 6 kyu solver should be able to solve it. I think. Also, I'm only trying to make some things explicit; I do not mean to insult you in any way. You have limited experience; I did as well when I was on here for a month and 26 kata. It also seems 6 kyu kata were easier then ( ranking by the community has changed over time ). Also, this is too long. :P

Could you please explain to me exactly what, and why, the problem is?

I'd like to understand why you use such big words ( "lie" ). I am not doing that intentionally, but of course I am testing for certain effects. Memoisation should affect side effects, and it's not like I'm doing it quietly.

Please consider that !cache[hash] may not do what you think it does if a function value is falsy, and / or you may want hash[cache] instead of cache[hash] if you wanted cache in hash.