The description says we need to "extract" names, but not what that means. Or what is to be returned by the functions.

JS starting code has an erroneous extra {.

I'm a UK guy. We use Mr. Not sure what the Wikipedia article was saying with that, but it's not right. Likely the same with the suffixes (though it's so rare to see one, I can't speak to experience with that.) I think it just depends on the situation, the context. A TV channel might drop the dots, a legal document might keep them, etc.

Just giving an example isn't enough. There is some amount of spec below that, but some things are left out--making it an incomplete spec. And making the resulting code kinda brittle, that passes only the tests you've written but it would fail other real-world cases.

I think it's just to show you what counts? Or something? They should just put it in the spec, in my opinion.

The part I'm confused about is... how many "biggest" values are you meant to be getting? Could someone explain how that works to me?

Because of these random tests, I don't think I'll be able to fully get them all to pass. There's usually only a few, but the number varies from run to run, so I'd only be getting lucky if I did pass it all. And when I look into the cases that don't pass, I don't think they're quite right by the looks of it.

So... it's a shame--I've sunk a few hours into this challenge, and it was pretty interesting. But I guess this is where I stop. ;/

It seems some of the tests have patterns that are simple objects, with set "matches" methods. Presumably we're meant to just call whatever the object's "matches" method is--regardless of where it has come from. I think that's how I'm doing it, but it wasn't clear to be from the description that how it must work.

It's explicitly saying you must set such methods on the prototypes. But that's not even necessary if you're just calling the method on the value you're given. So again, just a bit muddled with the potential of overlooking or misreading it.

I was given this by the randomised tests:

assert.strictEqual(patternMatch(
  [ [], [ [Array], {}, [Object] ], [ [Array], [Object], [Array] ] ],
  [ [], [Array], [Array] ], true
), true);

But I think it's incorrect. The pattern is expecting an array of 3 items:

• First item is an array of 0 items.
• Second item is an array of 1 item, an array (doesn't matter what it contains).
• Third item is an array of 1 item, containing an array (doesn't matter what it contains).

The input is an array containing 3 items:

• First item is an array of 0 items. [Pass]
• Second item is an array containing 3 items. [Fail]

...Right?

Or even String objects with a set .toString method which messes things up, for example? Not sure how you want such things handled though.

I don't know if you test for objects with { valueOf } or { toString } that make them look like other objects, but that could be a good test.

There are no sample tests for null or undefined that I got. Not strictly necessary--but to have such full coverage in the sample tests, but not quite all the basic ones seems like an oversight.

"Properties do not need to be defined on the input for a match to succeed." Does that mean it has to be set on the input, but the value can be undefined? Can you have pattern={a:String}, input={} and that's fine? What about pattern={a:String}, input={a:undefined}? Not clear how this works, to me.

Regarding the whole "matches" clarity issue, same goes for the section on objects, as well as arrays.

Then later I set up a "(Function)[matchesSymbol]" and that resolved itself. Some weird messages being given here. Perhaps a bug or mis-type in the tests?