Shorter https://www.codewars.com/kata/reviews/5266876c8f4bf2da9b000365/groups/66bf3ade1baad7bd715acf82

this is js )

Insane JS techinical skill level, congratz

What in the name of god

what even is this?

approved at kyu 6

ad 2: but it is not clear from the description if Function anonymous is sfunctor or sfunctor(), which have different behaviours.

1. I made the call logs as informative as possible
2. added sfunctor.test to the example description
3. moved the code from Preloaded

This is a generally bad example of code, but I like the look of it)

Using undeclared variables is not a best practice. f pollutes the global namespace ( and might be overwritten there ).

Example tests are unreadable for solvers. They heavily use Preloaded code, which is not available to solvers, and we have to assume behaviour from names. This is not the intent of example tests.

Show the Preloaded code in the description, or at least explain what everything does, or move the code into Example tests ( and also into Submit tests, but that's your problem ), or - much preferred - write more readable code in Example tests. Code duplication is not a ( solver ) problem there; example tests are meant to be readable for solvers, and individual tests should preferably be visible in the window in their entirety, without having to scroll to find definitions of factored out code.

Example test #2 tests sfunctor.test. From the description, it is not clear that sfunctor.anythingButVal should exist, because it does not yet have state.

Either only expect sfunctor().anythingButVal to exist, or specify better that sfunctor.anythingButVal uncalled should return either sfunctor() or sfunctor ( and which one, and possibly why ).

The former option would make more sense IMO.

The same goes for sfunctor.val - the state is initialised on first call; what is the expected value here, and why? ( I don't know if this is actually tested. )

Alternatively, sfunctor could immediately have a default state, which might be overwritten normally on first call. But the initial code indicates this is not how things work.

done

I mean you had a perfectly working way of extracting the state, which allowed keeping state in a closure. Now I have to keep state in .val. This adds complexity, but not functionality. It's useless.

And if you want fn.key, isn't that just fn ? Now I have to wrap things in a Proxy to handle "any (!) property". ( OK, the property access handler that's necessary for this means I can just get val from the state in the closure again. ) But again, it adds complexity without adding functionality; it's useless.

Adding unrelated tasks increasing complexity ( or worse, to add complexity ) is not a good way of upranking your kata.

I'll have it fixed within the hour.