Promise finally

[Raul-Sebastian Mihăilă]

This is an illustration of the current `Promise.prototype.finally`
deficiency. In this example, the `incr` method does 2 things. It increases
`count` by 1. And increases `methodCallsCount` by 1. At a later point in
time, it was decided to add an `incr3` method that did the same, but
increase `count` by 3, not by 1. There are two approaches illustrated, the
good counter and the bad counter. `Promise.prototype.finally` is currently
the bad counter. The good counter's `incr3` does exactly what it was
supposed to do, namely increases `count` by 3 and increases
`methodCallsCount` by 1. The bad counter's `incr3` calls `incr` 3 times in
order to increase `count` by 1 three times, thinking that it's equivalent.
The problem is that `incr` wasn't just increasing `count` by 1. It did more
than that. Therefore `incr3` is not expressible in terms of `incr`.
Similarly, `Promise.prototype.finally` shouldn't call
`Promise.prototype.then`, because, conceptually, it's definition doesn't
say that it must incur 2 extra ticks.

It's possible that library and framework authors will avoid using `finally`
for efficiency. The meeting notes don't illustrate that TC39 considered
this nuance seriously. Is it possible for TC39 to reconsider this matter?

```js
class GoodCounter {
  constructor() {
this.count = 0;
this.methodCallsCount = 0;
  }

  incr() {
this.count += 1;
this.methodCallsCount += 1;
  }

  incr3() {
this.count += 3;
this.methodCallsCount += 1;
  }
}

class BadCounter {
  constructor() {
this.count = 0;
this.methodCallsCount = 0;
  }

  incr() {
this.count += 1;
this.methodCallsCount += 1;
  }

  incr3() {
this.incr();
this.incr();
this.incr();
  }
}

const c1 = new GoodCounter();

c1.incr();

c1.count; // 1
c1.methodCallsCount; // 1

c1.incr3();

c1.count; // 4
c1.methodCallsCount; // 2

const c2 = new BadCounter();

c2.incr();

c2.count; // 1
c2.methodCallsCount; // 1

c2.incr3();

c2.count; // 4
c2.methodCallsCount; // 4
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Destructuring into object

[Alex Shvets]

Yes, I've read it, but I doesn't find something like this:

target.{a,b,c} = srcObject

Thank You!
- Alexander Shvets
https://github.com/transpiling/destructuring-into-object
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Destructuring into object

[Bob Myers]

I presume you've read the historical threads on this topic, which go back
several years.
Bob

On Mon, Feb 26, 2018 at 11:04 AM, Alexander Shvets 
wrote:

> # The Problem
>
> ES6 destructuring syntax isn't very readable and useful, especially for
> assigning to properties of existing object:
>
>  // ES6
> ({
>a: target.a,
>b: target.b,
>c: target.c,
> } = srcObject);
>
> // Versus ES3
> target.a = srcObject.a;
> target.b = srcObject.b;
> target.c = srcObject.c;
>
> There is no reasons to start using new ES6 destructuring syntax now, old
> syntax is better, because:
> - there is hard to assume that `target` object will be modified, if
> developer does not familar with new standart
> - identifiers are still duplicated
> - you should write braces `()` or use other solution, because JS statement
> cannot starts with `{`
>
> # Proposal
>
> So, in addition to current ES6 syntax, I want to propose this sugar:
>
> target.{a,b,c} = srcObject
> //alternative// target.* = srcObject{a,b,c}
>
> ## Why?
> + This syntax is more clear and understandable:
>  even without ES6 knowleges, developer can assume that some properties
> assigned to the left-side `target` from a right-side `srcObject` variable.
> + The one of destructuring goal is met: full elimination of identifiers
> duplication.
> + You can omit braces `()` because JS statement doesn't starts with `{`
> now.
>
>  New syntax for Object.assign()
>
> let target = {a:0}
>
> target.* = {b:1, c:2}
> //alternative// target.{} = ...
>
> console.log(target) // {a:0, b:1, c:2}
>
> Useful for:
>
> + adding properties to the `this` object in constructor
> + adding methods to the prototype of class
>
>  Extracting properties into local variables
>
> let * = {a:1, b:2} // like import * from 'module'
> console.log(a, b) // 1 2
>
>
> GitHub Repo:
> https://github.com/transpiling/destructuring-into-object
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Destructuring into object

[Alexander Shvets]

# The ProblemES6 destructuring syntax isn't very readable and useful, especially for assigning to properties of existing object: // ES6	({	    a: target.a,	    b: target.b,	    c: target.c,	} = srcObject);		// Versus ES3	target.a = srcObject.a;	target.b = srcObject.b;	target.c = srcObject.c;There is no reasons to start using new ES6 destructuring syntax now, old syntax is better, because:- there is hard to assume that `target` object will be modified, if developer does not familar with new standart- identifiers are still duplicated- you should write braces `()` or use other solution, because JS statement cannot starts with `{`# ProposalSo, in addition to current ES6 syntax, I want to propose this sugar:	target.{a,b,c} = srcObject	//alternative// target.* = srcObject{a,b,c}## Why?+ This syntax is more clear and understandable:      even without ES6 knowleges, developer can assume that some properties assigned to the left-side `target` from a right-side `srcObject` variable.+ The one of destructuring goal is met: full elimination of identifiers duplication.+ You can omit braces `()` because JS statement doesn't starts with `{` now.   New syntax for Object.assign()	let target = {a:0}		target.* = {b:1, c:2}	//alternative// target.{} = ...		console.log(target) // {a:0, b:1, c:2}	Useful for:+ adding properties to the `this` object in constructor+ adding methods to the prototype of class	 Extracting properties into local variables	let * = {a:1, b:2} // like import * from 'module'	console.log(a, b) // 1 2GitHub Repo:https://github.com/transpiling/destructuring-into-object
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Promise finally

[Raul-Sebastian Mihăilă]

I made the PR on the ecma repo so that the diff is smaller (since I'm
touching more sections than the proposal repo had).
https://github.com/tc39/ecma262/pull/1118/files

On Sun, Feb 25, 2018 at 5:27 AM, Jordan Harband  wrote:

> Simply theorizing about how it might be done - without an actual spec diff
> (this email might be close but I can't personally reason about it) - isn't
> going to achieve much, unfortunately.
>
> However, if you'd like to make a PR to the proposal repo, I'd be happy to
> review it. If it seems possible, and if it passes the test suites, I'd be
> happy to make the corresponding PR to the actual spec and test262.
>
> (as for "waiting a year", ES is a living standard; there's no need to wait
> that long. If a change is presented that results in fewer observable calls
> without violating any of the criteria that led to the current spec, I
> suspect the committee and implementors would be more than happy to see the
> change go in ASAP)
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Async Class

[Dimitrian Nine]

([Classes][1]):
[1]:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes
«JavaScript classes, introduced in ECMAScript 2015, are primarily
syntactical sugar over JavaScript's existing prototype-based inheritance.
The class syntax does not introduce a new object-oriented inheritance model
to JavaScript»
«Classes are in fact "special functions"»

```js class = function Create(); ```
all i want:
``` js async class = async function Create(); ```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss