Draft

S-functor

7Lambdius
Description
Loading description...
Recursion
View
AllIssues4Questions1Suggestions2Show Resolved
  • Please sign in or sign up to leave a comment.
  • JohanWiltink 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.

    • Lambdius 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
    • JohanWiltink Avatar

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

    • JohanWiltink Avatar

      Also, the handler must be available immediately, but what is the expected value for sfunctor.val ? The state is not yet defined at that point.

  • JohanWiltink 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.

  • JohanWiltink 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" ).

  • Kacarott Avatar

    I like the task, but currently the description essentially requires the solver to imply behaviour from examples. You have a Task section which starts with an introductory paragraph, and then just ends? I think you need to move the Notes to the end of the description, and also actually explain what this sfunctor actually is before you start clarifying behaviours. Keep in mind that many solvers will likely have even less of an idea of functional programming than you, and so the term "functor" may very well mean nothing to them.

    With a good description, I think this could be a nice task.

  • JohanWiltink Avatar

    Can state be null ? It can't be undefined, but it would simplify solving if it can't be null either.

  • JohanWiltink Avatar

    Method of testing is unspecified. What are we supposed to do with "state" ?

    • Lambdius Avatar

      please close your issues so I can publish the corrections.

    • JohanWiltink Avatar
      Issue marked resolved by JohanWiltink 15 months ago
    • JohanWiltink 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. )

    • Lambdius 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 (

    • Lambdius 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.

    • JohanWiltink 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.

  • JohanWiltink Avatar

    Empty state is unspecified. "does nothing" is expected to return a value anyway.