Kata

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. ;/

The test you mentioned does look incorrect to me, but I can't reproduce the issue or figure out how it might have happened.

I've re-validated my own solution a few times with no issues, so if you are getting a lot of randomised test failures it is probably an issue with your solution.

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

toString isn't considered and isn't supposed to have an effect on anything, but valueOf matters and is hinted at by the description at one point.

This should be covered by the primitive tests.

What this is saying is that there is no special handling for a non-existent property and it should be treated the same as if it existed but had an undefined value. Sometimes things behave differently based on that, i.e. in some cases, if we have the following code:

const objA = { prop: undefined };
const objB = {};

Some things will treat objA and objB differently, even though objA.prop and objB.prop are both undefined. We don't want any special handling here, so the patterns { prop: undefined } and { prop: () => true } should match both objA and objB.

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?

Possibly the confusion here is because that test is checking for [matchesSymbol] on Number (a function) and not Number.prototype.

As with Symbols, Sets are supposed to be compared with ===. The __name thing is used by the tests for display purposes, it isn't supposed to be accessed by the solution.

Technically every comparison is specified - anything that isn't explicitly covered in the description is supposed to use the fallback logic at the bottom of the Details section (i.e. basically ===).

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

The whole [matchesSymbol] thing is just a bit odd to me. A simple method would work perfectly well, and would no longer require Symbol use and understanding--which is not what this kata is about.

The idea is that a symbol is the better approach because it guarantees there will be no name conflicts (i.e. things don't break if we have a user-defined type with a matches method that does something different, or matches gets added to the RegExp object and doesn't do what we want it to). Understanding of more advanced JavaScript concepts is intended to be part of the kata's challenge.

"Why [matchesSymbol]? Using matchesSymbol enables custom pattern-matching behavior for user-defined types." Well... it doesn't; we have to implement it. Having a simple method would work exactly the same way.

It enables it because it allows you to implement it. It's providing a hook for custom pattern matching behavior - if one doesn't exist then you can't define your own pattern matching logic for your own types.

"If we have the following class...then the following code will work." Again, no it won't, because we have to implement that. There's nothing inherent to using a Symbol for this that means this works, when not using a Symbol would mean it wouldn't work. It's just a choice you made for some reason.

I mean, the class implements [matchesSymbol], so it will work. :)

You could even just leave this whole thing out and let the user implement it however they wish to. Just tell them what the main patternMatch() function needs to do, and let them do it however they wish. That would be exactly the same amount of challenge, they can choose if they want to split code across the prototypes or not, etc.

IIRC I originally wrote it that way, but then I realized basically everyone will build something that isn't extensible, which wouldn't be ideal. I redefined everything in terms of [matchesSymbol] so that a passing solution has to be extensible.

Technically the [matchesSymbol] handling could be required only for custom stuff, but I think it's better if everything is consistent.

If you keep the prototype method idea, you could give a clear list of prototypes to implement the method for instead of leaving it to the user to figure out. That doesn't add to the challenge, it's just not explicitly defined in an easy to read manner.

The hope is that it can be figured out by looking at the bullet points in the Details section. If you treat the Details section as a technical spec/strange form of pseudocode, you should find that it actually spells out most of a working solution for you.

"A function matches if: ..." Doesn't say if both conditions must be true, or at least one of them must be true.

It's at least one. I'll update the description to clarify. EDIT: Done.

"An array matches if...[all] elements match their corresponding element in the input" Unclear what is meant by "match" here.

See above point about the Details section being like a technical spec - you should find that "match" always has the same meaning throughout, i.e. in this case it's expecting you to recursively apply the full matching logic.

Perhaps the issue is, you started by talking about patterns matching values. But further down you're talking about values matching values

The idea is that there is no distinction - a pattern is always a value.

"{ nonExistent: undefined } matches {}" It's not clear which is the "pattern" and which is the "input" in that text.

Back to the point about Details being like a spec - "X matches Y" terms always have the same meaning, i.e. it's "<pattern> matches <input>".

Unclear why I would need that _() function instead of just returning true. I guess maybe some sort of "functional" thing, or monads, or whatever... but if the user wants to write the code that way, they'll know how to write const _ = () => true;. Not a big deal, just felt superfluous to me.

It makes things more concise and brings the "syntax" in line with what you find for pattern matching in a lot of other languages. It's a pre-defined variable so your solution shouldn't need to do anything about it.

This should be fixed now.

Needs additional fixed test cases for matching falsy values with {}:

I've added NaN/false/0/'' tests under "Object tests". The null/undefined cases were already there.

Also needs more tests for Sets:

I've added those test cases.

Because it's cool!

In fairness, I'd never use this in a real project, but I thought it would make a neat kata.

I agree the idea is neat, but the implementation seems to turn into just handling special case after special case, and sometimes special case within special case.

I haven't solved yet, but the idea seems better than the implementation and execution. JS has very inadequate support to do what is asked, and particularly the encoding of constructor instances goes actively against how the objects used for patterns work.

It seems any solutions will necessarily be kludges, instead of showcases of elegance. ( Please prove me wrong! )

Hopefully you will think my solution (once you can see it) is reasonably clean.

It's the pattern, so you can skip almost all matching if the pattern is null. Other patterns (e.g. () => true) can match null.

The wording for this is now "null matches if the input is null".

That part is supposed to be implying that the solution needs to define properties on one or more prototypes (with the matchesSymbol as the key) - the pattern arguments are just ordinary values, pattern[matchesSymbol] won't exist if the solution doesn't define it.

I agree that part is a little unclear and I'll have a think about how to improve the explanation.

( Why do we need to work with pattern[something] instead of just with pattern ?!? )

It's to enable special handling for custom types. E.g. if I made a Point class (storing a 2D coordinate) and then tried to use a Point(_, _) pattern, it wouldn't work by default, but I could override [matchesSymbol] and implement logic that made it work.

I've reworked the description, added an example of overriding [matchesSymbol], and added the following to the initial solution:

Object.prototype[matchesSymbol] = function (input) {
  
};

What do you think?

If you mean "How does 1 match to {}?", it doesn't (the match will never succeed). If you mean "How does 1 match to new Number(1)?", it unwraps the Number and matches successfully (i.e. 1 matches 1).

I meant input 1 to pattern {}.

1 is not null or undefined, so that should match, no?

1 is a primitive, not an Object, but the same goes for null and undefined.

1 is not null or undefined, so that should match, no?

Correct. {} matches 1, but not null or undefined.

1 is a primitive, not an Object, but the same goes for null and undefined.

I've drawn the distinction this way because 1 can act like an object in a way that null and undefined can't. Specifically, (1).a returns undefined, while null.a and undefined.a throw errors.

Don't we have null?.a in Node 14 now? ( I'm not yet used to that being available now either. )

It seemed like specifically mentioning and not mentioning certain things in the descriptions implied things, and those implications seemed to be incorrect or inconsistent.

Don't we have null?.a in Node 14 now? ( I'm not yet used to that being available now either. )

True (and null?.['a'], which I just found out about), but I still think it would be strange for {} to match null.

I think it's worth mentioning that { a: undefined } should match 1, even though 1 doesn't have an a property, because 1['a'] is undefined. When matching against null there has to be some kind of check to avoid trying to access a property, and I thought the right course of action would be to detect null and say that the pattern doesn't match. It would be strange to have all object literal patterns not match null except for {} (for which the pattern matching never needs to access a property, so never needs to check for null before doing so), so I added the rule that {} can't match null/undefined.

It seemed like specifically mentioning and not mentioning certain things in the descriptions implied things, and those implications seemed to be incorrect or inconsistent.

Could you elaborate on this and maybe I can clean up the description some more?

I've reworked the description some more, so hopefully things are clearer now. The object explanation is now:

• A plain object matches if the input is not null or undefined and all of the pattern's enumerable string-keyed properties match their corresponding value in the input (pattern[key1] matches input[key1], pattern[key2] matches input[key2], etc.).
  • Properties do not need to be defined on the input for a match to succeed: { nonExistent: undefined } matches {}.
  • The solution may use either the enumerable string-keyed properties or the own enumerable string-keyed properties of the pattern. The difference in behavior will not be tested.

My reasoning here is that a properly designed constructor will "do no work", so it should be safe to assume the Errors are input validation errors that can be ignored.

If you mean "they have no side effects", no, almost nothing should. But they will return their argument turned into a valid whatever it is they make, and that will almost always be truthy.

The real problem is we don't know when to handle a function as a constructor, so we're condemned to do special casing for a certain list of functions ( Boolean and others ), and this list can also never accommodate custom constructors.

This is handled by requiring an invoked function to return true rather than something truthy. This makes Boolean the only "normal" special case. It would theoretically be possible to define a custom class that needed special treatment like Boolean, but it wouldn't be a normal thing to do and the issue could be resolved by defining a [matchesSymbol] override for the constructor function of the new class.

(Pretty sure there is actually no way to define another special case class, at least as long as the solution uses ===.)

I realized the description incorrectly implied there was more than one exception to consider ("An exception to this rule is the Boolean function..."). In the context of the default rules, Boolean is the only exception, so I've updated the description to reflect that.

My view here is that pattern matching and an equality check are not the same thing (an equality check can be used for a pattern match, but that's an implementation detail), so it's OK to deviate from JavaScript's (widely regarded as awful) standard behaviors.