5 ms·

Is not `switch` enough for this?

cevn 9y ago
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' }
- Zyst 9y ago
  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) Which is, of course, still less terse. What I normally use when I have cases like this is an object-as-a-map. IE: const dates = { 1: 'mon', 2: 'tues' } let day = dates[3] || 'wed';
  - codedokode 9y ago
    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.
    - Prefinem 9y ago
      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)));
      - goatlover 9y ago
        That one liner has a lot going on. The first one is easier to read.
        mpfundstein 9y ago
        no
        codedokode 9y ago
        Please also look at my idea how to rewrite the code for readability using `deferred` pattern: https://news.ycombinator.com/item?id=16933983 https://news.ycombinator.com/item?id=16933983
      - codedokode 9y ago
        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.
        Prefinem 9y ago
        > 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: <a onClick={this.onClickEvent.bind(this)}>Click Me</a> becomes this: <a onClick={(event) => this.onClickEvent(event)}>Click Me</a> [0] https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/Promise.jsm/Deferred https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_...
    - Zacru 9y ago
      But function getDate(date) is hoisted. The const version isn't.
      - codedokode 9y ago
        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?
zdragnar 9y ago
From looking at the proposal, there are substantial differences. The biggest is that switch is an equality test on a single value, while pattern matching as proposed allows matching on multiple properties of an object, as well as conditional clauses. I need to look at it more closely, as some languages have matching be an expression, rather than a statement or block like the conventional switch. It doesn't add something that you can't already do- tcomb and other libraries offer functions that mimic it- but it changes the way you can express certain ideas without needing them, in a way that is already familiar from other languages. EDIT: yes, it does look like an expression, which means it can be used in many more places than a standard switch.

cevn 9y ago

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' }

Zyst 9y ago
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) Which is, of course, still less terse. What I normally use when I have cases like this is an object-as-a-map. IE: const dates = { 1: 'mon', 2: 'tues' } let day = dates[3] || 'wed';
- codedokode 9y ago
  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.
  - Prefinem 9y ago
    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)));
    - goatlover 9y ago
      That one liner has a lot going on. The first one is easier to read.
      - mpfundstein 9y ago
        no
      - codedokode 9y ago
        Please also look at my idea how to rewrite the code for readability using `deferred` pattern: https://news.ycombinator.com/item?id=16933983 https://news.ycombinator.com/item?id=16933983
    - codedokode 9y ago
      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.
      - Prefinem 9y ago
        > 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: <a onClick={this.onClickEvent.bind(this)}>Click Me</a> becomes this: <a onClick={(event) => this.onClickEvent(event)}>Click Me</a> [0] https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/Promise.jsm/Deferred https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_...
  - Zacru 9y ago
    But function getDate(date) is hoisted. The const version isn't.
    - codedokode 9y ago
      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?

zdragnar 9y ago

From looking at the proposal, there are substantial differences. The biggest is that switch is an equality test on a single value, while pattern matching as proposed allows matching on multiple properties of an object, as well as conditional clauses. I need to look at it more closely, as some languages have matching be an expression, rather than a statement or block like the conventional switch. It doesn't add something that you can't already do- tcomb and other libraries offer functions that mimic it- but it changes the way you can express certain ideas without needing them, in a way that is already familiar from other languages. EDIT: yes, it does look like an expression, which means it can be used in many more places than a standard switch.