Live data from Hacker News

JavaScript Pattern Matching Proposal

github.com

241–250 of 254 posts

Re: JavaScript Pattern Matching Proposal

#241

Earlier quoted context omitted.

Can you elaborate? What do you mean "match objects by their fields"? How does the proposal not already do that?

Maybe I did not express my self correctly, what I meant was - in it's current state the proposal rquires, when matching against an object, to specify all it's fileds, say you have an object with keys a, b, c then even if you match soley against the values of a , b you are required to specify c and by doing so notify it's existence. This poses a problem , since if you now remove c or add a filed d then the match will…

> in it's current state the proposal rquires, when matching against an object, to specify all it's fileds, say you have an object with keys a, b, c then even if you match soley against the values of a , b you are required to specify c and by doing so notify it's existence

I think this is wrong. The proposal says that a pattern like `{x}` matches if the object supports `ToObject` and if its `x` property is not undefined. It doesn't say anything about requiring that the object have no other own-properties. This is consistent with how destructuring already works in JS (it ignores any extra properties).

Re: JavaScript Pattern Matching Proposal

#242
post #140

Earlier quoted context omitted.

I like it, especially `default` instead of `{}` The leading curly braces in the linked proposal _are_ a bit odd to see, though the repetition of `case` isn't too fun either.

I suspect the example in the proposal refers to an object that doesn't match any of the previous options, but is still an object. For a default I'd expect there to be another pattern.

The default pattern is a variable name.

> [About variable name patterns binding to the name] Eliminates the need for an else/default leg, because assignment to any variable will be sufficient. JS programmers are already used to assigning variables that are then ignored (in functions, in particular), and different people have different tastes in what that should be. _, other, etc, would all be perfectly cromulent alternatives.

Re: JavaScript Pattern Matching Proposal

#243
post #141

Earlier quoted context omitted.

> But a large percentage of JS developers don't really have much background in non-mainstream languages or programming language theory Not to side-track the issue, but I keep hearing this. I'm wondering if this is true, and if so, how such a statement is verified. I'm currently a full-time JS dev, but have written my own programming languages, have professionally written in C, C++, C#, F#, Ruby, and others, and have…

I think you're a super anomalous member of any programming language's community. I doubt even one programmer in a thousand has written F# professionally (not being hipster here — I haven't done it myself).

Who are you calling a hipster....

Re: JavaScript Pattern Matching Proposal

#244
post #66

Interestingly, the match construct is an expression, which I don't think JavaScript has m/any of. Perhaps they could retroactively make if/else expressions, if that doesn't break back-compat.

Javascript already has a conditional expression, the ternary operator: `condition ? expr-if-true : expr-if-false`.

It doesn't have code blocks (aside from self-executing lambdas) and is very hard to reason about when nested.

Re: JavaScript Pattern Matching Proposal

#245

Earlier 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)));

Yes, there are cases when arrow functions are useful: when small functions are used inline, like this:

    var numbers = [1, 2, 3, 4].map(x => x * x);
    var bestUsers = users.filter(u => u.getRating() > 100);
But for a case when you have a large non-anonymous function, `function` keyword suits better. You don't need to use `const` keyword just becase it is something trendy now.

In your example, the code with arrow functions is smaller, but it is not more readable. Because there is no indentation, it is difficult to understand how code is nested. I cannot read that.

It can be rewritten using `deferred` pattern:

    var deferred = new Deferred;

    methodOne(data, function (error, response) {
        if (erorr) {
            deferred.reject(error);
        } else {
            deferred.resolve(response);
        }
    });

    return deferred.getPromise();
This way we can get rid of a callback in the Promise constructor. Please note that our code now looks sequential and we clearly see what happens after what. Asynchronous code is difficult to write and read; therefore we must put an extra effort to make it easier.

In my opinion it is generally bad idea to nest more that 1-2 levels of functions inside each other.

Re: JavaScript Pattern Matching Proposal

#246

Earlier quoted context omitted.

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.

Please also look at my idea how to rewrite the code for readability using `deferred` pattern: https://news.ycombinator.com/item?id=16933983

Re: JavaScript Pattern Matching Proposal

#247
post #174

Earlier 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.

But function getDate(date) is hoisted. The const version isn't.

I don't think it is a good idea to rely on such subtle differences that are not well known among developers. We want to write code that is easy to maintain, not compete in knowing ECMA specs, right?

Re: JavaScript Pattern Matching Proposal

#248

Earlier quoted context omitted.

Here you are: var x = match (response) { case { status:200 }: true; case { status: 404 }: new NotFoundError; case Number: Math.PI; case SomeClass: 1; case /^http/: "http error"; default: -1; };

I like it, especially `default` instead of `{}` The leading curly braces in the linked proposal _are_ a bit odd to see, though the repetition of `case` isn't too fun either.

Braces can be used in many cases, but `case` keyword is used only in `switch` and `match` and is not ambigious. You can see what construct it is from the first word.

Re: JavaScript Pattern Matching Proposal

#249

Earlier quoted context omitted.

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)));

Yes, there are cases when arrow functions are useful: when small functions are used inline, like this: var numbers = [1, 2, 3, 4].map(x => x * x); var bestUsers = users.filter(u => u.getRating() > 100); But for a case when you have a large non-anonymous function, `function` keyword suits better. You don't need to use `const` keyword just becase it is something trendy now. In your example, the code with arrow function…

> A Deferred object is returned by the obsolete Promise.defer() method to provide a new promise along with methods to change its state.

> Starting from Gecko 30, this object is obsolete and should not be used anymore. Use the new Promise() constructor instead (or use the above backwards/forwards compatible Deferred function given below). For example, the equivalent of

Seems like it's obsolete. [0]

If you want to write async code, use async / await.

    const run = async () => {
        const response = await new Promise((resolve, reject) => methodOne(data, (e, res) => e ? reject(e) : resolve(res)));
    };
If you spend enough time with fat arrow, it's as easy to read as `function` is. On top of that, IMO it looks cleaner. It also allows you to do scope binding in a different manor which in React is much better.

This:

    Click Me
becomes this:

     this.onClickEvent(event)}>Click Me
[0] https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_...

Re: JavaScript Pattern Matching Proposal

#250

Earlier quoted context omitted.

> we believe that the number of bugs is proportional to the number of lines of code Why would you believe that? And if you do believe that why don't you use a code golfing language?

What exactly are you contributing by taking what they said to the extreme? Should someone now have to point out to you that a million-line function is worse than a ten-line function for calculating fizzbuzz? Is that meaningful discourse in your book?

My response seems to have upset you. I'm sorry that happened.

In general I believe that number of lines of code is correlated with number of bugs, but I would hesitate to say that it is proportional to. Going in with the explicit goal of reducing the number of lines could easily lead to more bugs, not less.

Post reply on HN