I really don't remember what this was about, but are you referring to this?

Note: This kata uses the non-padding version ("=" is not added to the end).

Because I think that must have been added to the description after I had written the comment.

I can kinda see how has always seems to be used on a base object while having is used further down an expression chain (although this seems to be a distinction without any meaningful difference).

But with is brought up in the description without there being any significant difference between with and having:

// can define properties on nested items
jane.has(1).head.having(2).eyes.each( eye => being_the.color.blue.with(1).pupil.being_the.color.black )

What makes with(1).pupil the correct syntax for that expression vs. having(1).pupil? As far as I can tell they mean exactly the same thing.

The kata was probably changed to add numbers in addition to alphabetic characters.

(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.

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.