are there any 10+ year old languages that are "advancing" as quickly as JS? Ruby? Python? C++? Why Not?
You mean are there any other languages trying to quickly catch up to C++'s complexity?
JavaScript Pattern Matching Proposal
101–110 of 254 posts
Re: JavaScript Pattern Matching Proposal
#102I wonder if they can make it behave like Elixir's pattern matching. Multiple functions with different params, same name.
Elixir's multiple function heads are just syntax sugar for a case statement.
Re: JavaScript Pattern Matching Proposal
#103Earlier quoted context omitted.
By the way, I don't think it is a good idea to write a function as a constant. Please compare this function getDate(date) { .. } to this: const getDate = (date) => { ... } The first version is more readable. We instantly see that it is a function and in a second case it looks like a constant at first. Also without the equal and arrow sign it looks simpler.
Life is more fun with fat arrows sometimes new Promise(function (resolve, reject) { methodOne(data, function (error, response) { if (erorr) { reject(error); } else { resolve(response); } }) }) vs new Promise((resolve, reject) => methodOne(data, (error, response) => error ? reject(error) : resolve(response)));
That one liner has a lot going on. The first one is easier to read.
Re: JavaScript Pattern Matching Proposal
#104Could someone please explain what this could be used for ?
Pattern matching can be quite powerful, e.g. in C# (which I wish was more indepth / more featured, it still feels a bit immature :( ) ``` switch(foo) { case TextBox t: Console.Writeline(t.Text); break; case TextBox when t.Text = "Bob": Console.WriteLine("Hello Bob"); break; case Combobox c: Console.WriteLine($"{c.SelectedItem}"); break; case null: Console.WriteLine("Ooops, null!"); break; case int i when i == 5: Cons…
> Pattern matching can be quite powerful, e.g. in C# (which I wish was more indepth / more featured, it still feels a bit immature :( )
C# doesn't really deserve the name of pattern matching, just a type-based switch (with guards), you can't match on values let alone destructure them.
> Ugh, how do you format code?
4 spaces indent.
Re: JavaScript Pattern Matching Proposal
#105Earlier quoted context omitted.
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; };
so make switch first class? var x = (switch(true){ case response === { status: 200 }: return true; case response === { status: 404 }: return false; case response === Number: return 0; case response === SomeClass: return 1; default: return -1; });
> so make switch first class?
No. That would make the actual switch statement a value, rather than make switches expressions. And your version is completely different as you make cases into guards rather than labels or patterns.
Re: JavaScript Pattern Matching Proposal
#106Earlier quoted context omitted.
I would argue that it doesn't feel like JavaScript much which seems bad.
Why? To me it seems pretty aligned with the "feel" of destructuring.
In my mind there are several valid options out there now:
1. Regex style: new match(input, options);
or built in function match(foo, bar);
or like switch match (foo){ cases
}
But, to have the switch statement syntax and return a value seems like a less than good way to implement this.
Re: JavaScript Pattern Matching Proposal
#107What 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.
C's switch/case is essentially a special case with a limited set of values (literals) and no destructuring. You can extend it to less trivial patterns and blam pattern matching.
Re: JavaScript Pattern Matching Proposal
#108Looking at this as someone who's been writing a lot of ClojureScript lately, I'm reminded of how nice it is to be writing in a Lisp: if I felt this was the right syntactic construct for a common-enough problem in my codebase, I'd write a macro for it and get on with my life without having to wait for it to trickle through committees, compilers, and browser implementations.
Re: JavaScript Pattern Matching Proposal
#109Its an interesting concept but, The choice of syntax seems bad. The definition bit looks like a function definition but behaves entirely differently. Why? Why not make it a constructor like everything else? People could look at it and be like "oh a match object" instead of wondering if you overloaded function. The selectors look like json, only assignable. Again make it obvious.I mean we could even just make it json…
I made the same type of arguments about fat arrows but everyone told me to stop whining and I'd get used to it. Years later fat arrows still feel like a bad syntax choice.
Really? I quite like them. I did get used to them in C# first, though. What would you have preferred?
Re: JavaScript Pattern Matching Proposal
#110I'm not familiar with the JS proposal process. Is this likely to become an official feature now that it's been proposed? If so what's the usual timeline of that look like? I would love to have this feature ASAP in the browser and/or Node.js and am eager to find out when that will be possible.
This is a Stage 0 proposal. Basically it means somebody with a connection to the TC39 (the committee in charge of the JavaScript standard) has thought this was a good enough idea to put together into a proposal. In terms of chances of standardization, that's a step up from "Hey, I have a great idea", buy there are plenty of Stage 0 proposals that go nowhere because they lose steam. I think the metric they look for is…
Even Stage 4 isn't granted it will end up on the standard, some proposals have died on Stage 4.