Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More nested matching examples #8

Closed
bterlson opened this issue Jul 3, 2017 · 11 comments
Closed

More nested matching examples #8

bterlson opened this issue Jul 3, 2017 · 11 comments

Comments

@bterlson
Copy link
Member

bterlson commented Jul 3, 2017

Especially compositions of different matching types. For example, the following was raised by @marcfawzi on Twitter:

match (p) {
  { name: String, age: Number }: "valid input",
  else: "invalid input"
}
@cesarandreu
Copy link

How would you differentiate between p = {name: String, age: Number} and p = {name: '', age: 0}?

@itsMapleLeaf
Copy link

As @cesarandreu pointed out, this is problematic, since current semantics imply matching against the String and Number global object literal.

match (p) {
  { name: typeof 'string', age: typeof 'number' }: 'valid input'
  else: 'invalid input'
}

Something like this would be better, I think.

@ljharb
Copy link
Member

ljharb commented Jul 5, 2017

typeof wouldn't work for non-primitives, though - and for Array and other builtins, it should work cross-realm.

@itsMapleLeaf
Copy link

instanceof SomeObject then? Isn't there a thread on extensions to handle these edge cases?

@ljharb
Copy link
Member

ljharb commented Jul 5, 2017

instanceof doesn't work cross-realm, so it's pretty useless.

@bterlson
Copy link
Member Author

bterlson commented Jul 5, 2017

Perhaps I should rename this thread to 'brand checking'. I was talking to @sebmarkbage about this as well. Typeof and instanceof are both valid brand checks in some scenarios, but both also have problems. The problems are exacerbated by the various Realms proposal which will make cross-realm values more common. My feeling is that this proposal should make any brand check an error (eg. Symbol.matches on built-ins throws) until there is a cohesive proposal for brand checking. I don't think this proposal is where to drive that work...

@ljharb
Copy link
Member

ljharb commented Jul 5, 2017

One possible interaction between @jasnell's proposal, for example, could be that the default matcher on builtins uses the default brand check - I agree this proposal isn't where to drive that work, but I wouldn't want to see one of them land without considering the cross-cutting interaction with the other.

That said, that's a stage 2 concern, so it's way too early to worry much about it.

@7fe
Copy link

7fe commented Jul 5, 2017

@cesarandreu As discussed #6 I think using an operator like ~ or the @ symbol makes sense the left(name) and right side(instance of) of the operator would make sense. I have examples here #22

@7fe
Copy link

7fe commented Jul 5, 2017

@ljharb it is cross browser supported https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/instanceof I'm assuming you mean it doesn't work cross realm meaning it doesn't work between iframes because they are technically different objects yes?

@ljharb
Copy link
Member

ljharb commented Jul 5, 2017

@limeblack yes, that's what i mean.

@zkat
Copy link
Collaborator

zkat commented Mar 25, 2018

Hey y'all! #65 has gotten merged, and a lot of issues have become irrelevant or significantly changed in context. Because of the magnitude of changes and subtle differences in things that seem similar, we've decided to just nuke all existing issues so we can start fresh. Thank you so much for the contributions and discussions and feel free to create new issues if something seems to still be relevant, and link to the original, related issue so we can have a paper trail (but have the benefit of that clean slate anyway).

Note that the new proposal supports arbitrary layers of nesting, so I think this is resolved :)

@zkat zkat closed this as completed Mar 25, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants