Stop using (nested) ternary operator's ! Use if-statements!
if(val==1) var res = 1;
if(val==2) var res = 2;JavaScript Pattern Matching Proposal
41–50 of 254 posts
Re: JavaScript Pattern Matching Proposal
#42What an ugly syntax. They should follow switch/case syntax for consistency.
Pattern matching doesn't work the same way as switch/case though. Using that syntax would be misleading and confusing.
Why not? In Haxe (a statically typed language which compiles to js, amongst other targets) pattern matching happens in a switch:
https://haxe.org/manual/lf-pattern-matching-structure.html
Re: JavaScript Pattern Matching Proposal
#43Earlier quoted context omitted.
Is not `switch` enough for this?
It's more concise than switch, as well as more powerful (can destructure objects). You can't set things equal to the result of a switch. I find the pattern very convenient. let day; switch (date) { case 1: day = "mon"; break; case 2: day = "tues"; break; default: day = "wed"; break; vs let day = match(date) { 1 => 'mon', 2 => 'tues' }
In fairness I think that would look a bit more like this:
const getDate = (date) => {
switch (date) {
case 1:
return 'mon'
case 2:
return 'tues'
default:
return 'wed'
}
}
let date = getDate(1)
const dates = {
1: 'mon',
2: 'tues'
}
let day = dates[3] || 'wed';Re: JavaScript Pattern Matching Proposal
#44Earlier quoted context omitted.
Let's see an example of your proposed alternative syntax.
That's not how it works. You don't have to be Steven Spielberg to dislike some Hollywood movie. How is this fallacies called?
There's a totally different barrier of entry for that than suggesting a syntax. That's not even in the same stratosphere.
Re: JavaScript Pattern Matching Proposal
#45What an ugly syntax. They should follow switch/case syntax for consistency.
Let's see an example of your proposed alternative syntax.
I think an example would resemble how Swift integrated pattern matching into their regular switch statements, it doesn't require too much creativity to envision.
Re: JavaScript Pattern Matching Proposal
#46I can only see this being a foot gun. Deep equality testing of objects is going to encourage the use of getters. Getters with side effects (no way to prevent them) will basically ruin your day if you try to use pattern matching with them.
Additionally, this would be the first "native" way to do deep equality testing of objects. I can see it being abused to do simple one-off checks that could otherwise have been done more simply in an imperative way.
Do we really need to save the five lines of code at the cost of new syntax? This doesn't seem to prevent any significant amount of toil, since it can be pretty easily unrolled into existing JS syntax.
Re: JavaScript Pattern Matching Proposal
#47What an ugly syntax. They should follow switch/case syntax for consistency.
I think match cases should be functions, since you have built those anyway.
So instead of match (x) { expr... } you would have something like match(x, [ fn... ]) or match(x) { name: fn, name2: fn2 } where fn is like (objectToMatch) => { expr }
Re: JavaScript Pattern Matching Proposal
#48Out of the major, popular languages today, Javascript is easily the worst.
Don’t disagree, but what an odd place to state it. It's almost like you want to argue with js programmers.
Re: JavaScript Pattern Matching Proposal
#49What an ugly syntax. They should follow switch/case syntax for consistency.
Pattern matching doesn't work the same way as switch/case though. Using that syntax would be misleading and confusing.
I think there's an argument to be made that switch statements already do something adjacent to pattern matching. At the least, it's close enough that something like:
switch(expr) {
case 'foo':
break;
case { foo: bar }:
break;
}
Granted, it doesn't help make switch any easier to learn, but I _do_ think it makes switch more _rewarding_ to learn. Right now, switch is basically just a restrictive, potentially terser version of an if statement. This would make switch actually useful to learn.
It might even allow us to add some more semantics to switch over time (e.g. constructor matching with something like 'case Number').
(EDIT: thanks to armandososa for teaching me a new thing!)
Re: JavaScript Pattern Matching Proposal
#50Javascript is such a mess, this proposal looks really bad, and the guys discussing it are saying things like: "we should make sure that this doesn't look like anything else, so that people who learn the language don't confuse match and switch..." There is also a lot of "we shouldn't break that" messages, and people reply with "oh we already screwed that up here and there, so it's fine"...
ahh, the classic JS bashing from a dotnet or Java or PHP or Ruby or Python dev, or just by ignorance