Earn extra honor and gain new allies!
Honor is earned for each new codewarrior who joins.
Learn more
  • This comment is hidden because it contains spoiler information about the solution

  • This comment is hidden because it contains spoiler information about the solution

  • (JS)

    Since has, having, and with are synonyms, any of the following should be permitted, and should have the same result:

    jane.has(2).arms.each(arm => has(1).hand.having(5).fingers )
    jane.has(2).arms.each(arm => having(1).hand.having(5).fingers )
    jane.has(2).arms.each(arm => with(1).hand.having(5).fingers )
    

    As far as I can tell, only having is tested, and in fact with is a JS keyword so it's likely to cause problems for many solutions.

  • This comment is hidden because it contains spoiler information about the solution

  • The suggestion was to break it into several katas that gradually build up to this (I even gave examples of them, so it really shouldn't be confusing).

    But it's been 5 years since I suggested that, so you feel free to just not do it.

  • Probably a few hours, but it was a long time ago, so I really don't remember.

  • Yeah, passing an object with key-value pairs would be the easiest (and proper) way to give a function "named arguments". I.e., you'd change the function from function fnname(arg1, arg2) to function fnname({arg1, arg2}), and change the code that calls it from fnname(val1, val2) to fnname({arg1: val1, arg2: val2}).

    However, the kata challenge here was to hotfix a pre-existing function that takes ordinary arguments, so it implies that you can't or aren't supposed to modify the function... you're just supposed to wrap it in a new anonymous function that figures out what arguments it expects and provides defaults.

  • My first go at it wasn't efficient enough, but I came up with a faster algorithm. Now it runs in <4 seconds for all of the tests (Javascript).

  • Sure, now solve that kata without using __proto__ (which is a non-standard, internal object that you shouldn't ever use) or Object.create (which new predates; new cannot be syntactic sugar for something that didn't even exist yet).

    new is the correct method of doing this.

  • I actually wish you'd go into more detail on this:

    new is just a convenient syntactic sugar for creating and initializing an object

    I'm pretty certain it's not an accurate statement, but I'd like to know why you say it is.

  • I'm pretty sure that is incorrect. You have to use "new" in order to get an ArrayComprehension object that has the ArrayComprehension.prototype methods that were created. The description clearly indicates that it should return an ArrayComprehension object, and the preloaded solution shows that you're supposed to define ArrayComprehension.prototype methods, which won't work unless it is.

    Either the person calling the function has to do it (correct), or it doesn't (WRONG) -- then you have to stick at the top of the constructor a patch that detects this error and fixes it:

    if (!(this instanceof ArrayComprehension)) return new ArrayComprehension(...)
    

    ...but either way, you have to use "new". The proper place to use it is when calling ArrayComprehension to create a new instance of it. Skipping "new" and then patching the constructor function to detect and fix this omission is not a best practice. It will encourage sloppy coding and lead to coders who don't understand what "new" does.

    Using "new" when calling the constructor is best practice, and is what should be encouraged. It's not just convenient syntactic sugar; it actually creates a new object. If you use "new", the this object inside the constructor function will be that new object; if you don't use "new", this will not be a new object. And to create an object that will test as instanceof ArrayComprehension, the only correct way to do it is using new ArrayComprehension. You shouldn't use __proto__ to hack it.

    If I'm forgetting something here, give me specific examples of what you're talking about.

  • It looks like someone edited the description to something very similar to what you posted.

  • The description is clearer now, and I added the edge case where n==m to the description, examples, and tests for both languages.

    It looks like someone already edited the Javascript tests to use assertEquals. CoffeeScript's == operator compares for strict equality (equivalent to === in Javascript) so I think it's okay left as it is; someone else can edit the CoffeeScript tests if they think it's still an issue.

  • The description is clearer now and contains examples.

  • The description is clearer now and contains examples.

  • Loading more items...