4 ms·

No it's for I/O ops. Think cancelling a fetch() like you can do with XHR.

by explorigin 10y ago

nraynaud 10y ago
ah! that seem like the easy stuff.
- ralfn 10y ago
  But fetch() returns a promise, rather than a handler you can use to cancel the request. So some people wanted to add "cancel" as a third potential state of a promise. Which smells a bit like a hack to me. Why stop at cancel? The Fetch API shouldnt return a promise, maybe? But im assuming a lot of people gave it a lot of though. Maybe it is common enough. Maybe it is horrible to implement in a performant way. But so far the new ES features ive seen should have been critisized more not less. Look at the ugly mistakes that did make it: f => { pizza } Is the block on the right a statement block or an object literal? Its a statement block so if your lambda function returns an object literal than you need to wrap it in a statement block with a return statement. If it is anything else, than you dont. Thats the horrible crap that actually gets through the proccess. Imagine how naive and broken the propositions must be that get killed?
  - EvilTerran 10y ago
    > if your lambda function returns an object literal than you need to wrap it in a statement block with a return statement Or you can just parenthesise the object literal: >>> (x => ({ x }))(23) Object { x=23 } The grammatical ambiguity is unfortunate, sure, but the simplest work-around isn't so bad.
    - ralfn 10y ago
      If one forgets the (parentheses) you may or may not immediate or later can an error _somewhere_. It isn't about the workaround -- it's about all the subtle bugs it will introduce in the edge-cases, for example: f => () => {} f(); // undefined instead of empty object
  - 010a 10y ago
    It is a statement block. You need to say f => ({ pizza }) to get an object literal. This isn't that hard to understand.
    - ralfn 10y ago
      But it's easy to forget, just once. For example: x => () => {} x(); // undefined instead of empty object This can lead to immediate syntax bugs, eventual errors throws and silent semantic errors. Which reinforces the whole argument that they should think a bit harder about all the new features.

No it's for I/O ops. Think cancelling a fetch() like you can do with XHR.

nraynaud 10y ago

ah! that seem like the easy stuff.

ralfn 10y ago
But fetch() returns a promise, rather than a handler you can use to cancel the request. So some people wanted to add "cancel" as a third potential state of a promise. Which smells a bit like a hack to me. Why stop at cancel? The Fetch API shouldnt return a promise, maybe? But im assuming a lot of people gave it a lot of though. Maybe it is common enough. Maybe it is horrible to implement in a performant way. But so far the new ES features ive seen should have been critisized more not less. Look at the ugly mistakes that did make it: f => { pizza } Is the block on the right a statement block or an object literal? Its a statement block so if your lambda function returns an object literal than you need to wrap it in a statement block with a return statement. If it is anything else, than you dont. Thats the horrible crap that actually gets through the proccess. Imagine how naive and broken the propositions must be that get killed?
- EvilTerran 10y ago
  > if your lambda function returns an object literal than you need to wrap it in a statement block with a return statement Or you can just parenthesise the object literal: >>> (x => ({ x }))(23) Object { x=23 } The grammatical ambiguity is unfortunate, sure, but the simplest work-around isn't so bad.
  - ralfn 10y ago
    If one forgets the (parentheses) you may or may not immediate or later can an error _somewhere_. It isn't about the workaround -- it's about all the subtle bugs it will introduce in the edge-cases, for example: f => () => {} f(); // undefined instead of empty object
- 010a 10y ago
  It is a statement block. You need to say f => ({ pizza }) to get an object literal. This isn't that hard to understand.
  - ralfn 10y ago
    But it's easy to forget, just once. For example: x => () => {} x(); // undefined instead of empty object This can lead to immediate syntax bugs, eventual errors throws and silent semantic errors. Which reinforces the whole argument that they should think a bit harder about all the new features.