221–230 of 254 posts
https://github.com/zkat/proposal-pattern-matching
zkat (who is also an npm employee) is a leading committer to the tc39 version, so I think there's some chance that many aspects their version will be adopted into the proposal.
Earlier quoted context omitted.
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 }
It could look like this: var x = match (response) { case { status:200 }: true; case { status: 404 }: false; case Number: 0; case SomeClass: 1; default: -1; };
Earlier quoted context omitted.
If you mean by method-based pattern matching that you evaluate a function for each 'case'. My lib can do that do: const match = require('pmatch-js') const _ = require('lodash') const fizzbuzz = x => match(x) .when(a => a % 3 == 0 && a % 5 == 0, 'fizzbuzz') .when(a => a % 5 == 0, 'buzz') .when(a => a % 3 == 0, 'fizz') .otherwise(a => a) console.log( _.range(1, 101).map(fizzbuzz).join(' ') ) But maybe you mean somethin…
Wow, importing the whole lodash to use just one function? There’s es6 way of getting an array with a range of numbers: [...Array(100).keys()].map(v=>v+1) A little bit longer but no dependencies.
are there any 10+ year old languages that are "advancing" as quickly as JS? Ruby? Python? C++? Why Not?
Earlier quoted context omitted.
Even Stage 4 isn't granted it will end up on the standard, some proposals have died on Stage 4.
Any example? Since stage 3 is roughly "request for implementers", and Stage 4 requires 2 real world implementations and essentially mean "will be part of the standard in the next wave". The closest thing I can think of is ES6 modules, because the module loader spec wasn't finished, but the syntax still lived on. Now, stuff getting kicked down from Stage 3, that has happened.
You know that quip about C++ being an octopus made by nailing extra legs onto a dog? Is the same phenomenon somehow tasteful when it comes to ECMAScript {({..., sy: nt => ax, ...}({,})} ?
I feel like JavaScript is already a sort of functional language, so going in this direction is ok. It's the object/class additions where I think it's all going a bit C++. Start with prototypical inheritance, but with a Java-style `new` keyword that makes everything confusing. Next bolt on classes on the one hand, while correcting your prototype system `Object.create` on the other. R has 3 different object systems and…
If I do the following: let visFilter = 'foo'; const newState = match (action) { {type: 'set-visibility-filter', filter: visFilter} => console.log(visFilter) } What happens? Is it checking if action.type === 'set-visibility-filter' && action.filter === 'foo' or is it destructuring the value of action.filter into visFilter?
Every example in on the readme demonstrates that using an identifier in that position becomes destructured assignment.
To me this is pretty average and seems like it will cause magic numbers/strings/etc if I can't use constants where it makes sense. The proposed solution is to do something like
{ status: 200 } if (x === foo) => // do something
if (res.status === 200 && res.x === foo) //do something
This proposal will increase code coupleing by fixing the object structure, this will lead to refactoring problems and so on. A better approach would allow to match objects by their fileds while leaving the structure of the object unspecified.
Can you elaborate? What do you mean "match objects by their fields"? How does the proposal not already do that?
So I can do
let name = obj?.data[i]?.name;
And not get error can't read property data of undefined, when there is something wrong, just have undefined as value.
To fix this I've to write redudant checks for each level of nested property. Or do stuff like (obj || {}).prop....
Earlier quoted context omitted.
Apparently they're overloading the meaning of the => "fat arrow" in the proposed syntax. I agree it's confusing because it's already used with lambdas in case of JS, but many languages with pattern matching do use it (eg. Scala, Rust). Other languages like Haskell and F# use the thin arrow -> instead. Pattern matching can be exhaustive or non-exhaustive . Basically, if a match construct is going to be an expression i…
I believe all these languages, if they use some arrow in lambda syntax (so, except Rust), use the same kind of arrow for pattern matching. It's an obvious syntax choice when lambda arguments also use the same destructuring syntax: why would anyone want to remember which of those is `[x,y]->x+y` and which is `[x,y]=>x+y`?