Also, can I admit the proposal for the class type checking for the error handlers? For now, I can't see anymore having an eye on the open issue for example:
try {
unresolvableFilesFunction();
} except (e) {
case e
{FileException e} -> connsole.error('file', e.msg),
{FileExceptiopns err} -> conole.error('files', err),
{[...FileException err]} -> console.log('files array', err.map(e) => e.msg))
}
How would that work? instanceof is unreliable and doesn't work across realms, so you wouldn't be able to match Number here, for example.
@ljharb We are trying to put this into to the proposal, or to implement this into babel? This is why my thoughts is to make language to be more functional, sorry. Also sorry for a early replay
The current proposal does not have any sort of implicit "class" matching, so I'm assuming you're asking for the proposal to add that. I'm asking how that would be possible in a cross-realm way?
Maybe you'll be agreeing to add class before the class name? Because I think, whiteout the lexical signature it'll not work. But I think that this case should work to improve FP-programmers, also this can afford for us.
The question isn't how you'd syntactically distinguish this comparison - i'm asking how you would actually determine that something has matched or not, in a cross-realm way.
Specifically, how could you match new FileException() to FileException e?
This is a very hard to work to rewrite lexer?
I don鈥檛 know what you mean by lexer; my question has nothing to do with parsing. I鈥檓 asking about the runtime semantics.
instanceof of maybe .prototype.constructor checking. Maybe add something else.
I can't think for those other members of the community but I only can purpose the haskell switch pm where can ban be destructed by the type classes, for example:
js
take m ys = case (m, ys) {
when (0 ,_) -> []
when (_, []) -> []
when (n, x:xs) -> [x , ...(Array..splice(1, xs.length - 1))]
}
Neither of those work cross-realm, or are reliable. There鈥檚 nothing left I鈥檓 aware of that would make sense. JS doesn鈥檛 have type classes in the way Haskell does.
"instanceof" is a concept in JavaScript that it doesn't work cross realms doesn't preclude the usefulness of matching on classes for code that isn't operating on cross realm objects.
Yes, it does, because it wouldn鈥檛 work on builtin types.
You can already use instanceof if you like via a guard statement - but it shouldn鈥檛 have special syntax if it only works on custom objects.
Additionally, 3 is not instanceof Number, so how would it match primitives? It鈥檇 be extremely strange if it couldn鈥檛.
I'm going to close this; I have no intention of including instanceof semantics (except via guards, for which you can do whatever you like).
Most helpful comment
"instanceof" is a concept in JavaScript that it doesn't work cross realms doesn't preclude the usefulness of matching on classes for code that isn't operating on cross realm objects.