Ad
  • Custom User Avatar
  • Custom User Avatar

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

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

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

  • Custom User Avatar

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

  • Custom User Avatar

    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.

  • Custom User Avatar

    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.

  • Custom User Avatar
  • Custom User Avatar

    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.

  • Custom User Avatar

    I'll have it fixed within the hour.

  • Custom User Avatar

    All Example tests run in a single it. This means I have no clue where this message

    TypeError: Cannot read properties of undefined (reading 'val')
        at Context.<anonymous> (test.js:127:25)
        at process.processImmediate (node:internal/timers:471:21)
    

    is coming from.

    Separate example tests should run in separate its, preferably identifying the test in the header ( counting would suffice I guess, though I would like to see "inputs" ).

  • Custom User Avatar

    Property val must now return the state, and any other property must return sfunctor itself. Both seem unnecessary, and the second one seems especially fraught.

    please explain in detail what you mean.

  • Custom User Avatar

    I've added a specifics to the description.

    it should return original function with current state.

    I got the idea to extract the state after your questions, so I decided to complicate the task a bit.

    I'm sorry you didn't like the updates (

  • Custom User Avatar

    I see the specs have changed. Property var must now return the state, and any other property must return sfunctor itself. Both seem unnecessary, and the second one seems especially fraught.

    Implementing the second feature is complicated, the specs are unclear if it should return a clean sfunctor or one with the current state, it does not return anything that wasn't already accessible in simpler ways, and it's just an unrelated additional task. "Do one thing, and do it well." Stick to applying functions to values. The state was accessible the original way ( though keeping it in this.var is actually not too bad, but then why tell people to keep it in a closure? ), and sfunctor ( with either a new or the current state ) is also already available.

    I liked the first version better. ( That's my opinion. Other ones may be available. )

  • Custom User Avatar

    Just takes a few minutes to update

  • Loading more items...