a new ES6 spec. draft dis available

# Allen Wirfs-Brock (13 years ago)

As usual, at harmony:specification_drafts Changes include:

Significant reworking of the use of cover grammars for unambiguously defining assignment restructuring patterns and for arrow function formal parameters. Renaming of Quasis to Template Strings Incorporated Class definition semantic decisions from July TC39 meeting Make concise methods enumerable, as per Sept. TC39 meeting. A first cut at making Object.prototype.toString extensible via a Unique Symbol extension point. Started to rough in binary data and typed arrays into Section 15. At this point it is mostly just material copied directly from wiki proposals. Lots of integration and detailed specification work remains. Fully specified Map builtin as 15.14. This also serves as model for how other new built-in collections will be specified. Roughed in section 15 places holders for Set, Weakmap, Proxy, and the Reflect module. Feedback on overall organization of this material is welcome. Many fixes of both unreported and reported bugs, including:256, 464-468,470-479, 482-484,486,488,490-497,499,502,506,506-510,514, 515, 520, 521, 527, 529-537,539-559, 561-564, 566-569, 571, 572, 576, 579-587, 589, 592, 597-599, 601-609,612, 614-616, 618, 620-623, 626, 628-630, 633,635,639-644,650,653

# Yusuke Suzuki (13 years ago)

Great! ES6 rev10 draft is very interesting, so I'm now reading this changes...

And I've found typo in draft section 11.1.10, 11.1 StaticSemantics, , IsValidSimpleAssignmentTarge should be IsValidSimpleAssignmentTarget

, Yusuke Suzuki

# Herby Vojčík (13 years ago)

Allen Wirfs-Brock wrote:

As usual, at harmony:specification_drafts

Changes include:

*
  Make concise methods enumerable, as per Sept. TC39 meeting.

No! Why? Is there any meeting notes with it?

# Rick Waldron (13 years ago)

On Thu, Sep 27, 2012 at 3:12 PM, Herby Vojčík <herby at mailbox.sk> wrote:

Allen Wirfs-Brock wrote:

As usual, at **doku.php?id=harmony:**specification_draftsharmony:specification_drafts

Changes include:

*
  Make concise methods enumerable, as per Sept. TC39 meeting.

No! Why? Is there any meeting notes with it?

I'm waiting for some final reviews from members of the group, once those are complete I will publish the meeting notes.

# Yusuke Suzuki (13 years ago)

And I've found typo in Map implementation.

15.14.1.1 MapInitialization, step 6, internal method should be internal property

, Yusuke Suzuki

# Rick Waldron (13 years ago)

On Thu, Sep 27, 2012 at 3:47 PM, Yusuke Suzuki <utatane.tea at gmail.com>wrote:

And I've found typo in Map implementation.

15.14.1.1 MapInitialization, step 6, internal method should be internal property

Can you file a bug for this bugs.ecmascript.org/process_bug.cgi

# Yusuke Suzuki (13 years ago)

Thanks, I've filed them.

ecmascript#664, ecmascript#665, ecmascript#666

, Yusuke Suzuki

# Axel Rauschmayer (13 years ago)

B.3.1, “The proto pseudo property” will eventually be moved out of the annex, right?

If I may: I have two questions about this section.

  1. Quote: “Manipulations of this property as tracked by the Boolean valued primordial internal variable UnderscoreProtoEnabled.” What is a primordial internal variable? That term does not appear anywhere else in the spec.

  2. Quote: “The default initial value of UnderscoreProtoEnabled is true only if this property is initially present on the primordial Object prototype object.” I would have guessed that the variable being true also depends on whether or not Object.prototype is in the prototype chain.

Thanks!

Axel

# Allen Wirfs-Brock (13 years ago)

Nothing new in this section in this draft and what is there will eventually get a significant rewrite...

On Sep 27, 2012, at 9:32 PM, Axel Rauschmayer wrote:

B.3.1, “The proto pseudo property” will eventually be moved out of the annex, right?

If I may: I have two questions about this section.

  1. Quote: “Manipulations of this property as tracked by the Boolean valued primordial internal variable UnderscoreProtoEnabled.” What is a primordial internal variable? That term does not appear anywhere else in the spec.

No doubt the terminology will change, if we still need it. What it is describing is a per global context (per "realm") internal variable.

  1. Quote: “The default initial value of UnderscoreProtoEnabled is true only if this property is initially present on the primordial Object prototype object.” I would have guessed that the variable being true also depends on whether or not Object.prototype is in the prototype chain.

No, in this draft, it is just tracking manipulation of that specific property of Object.prototype. The inheritance aspects are taken care of in the [[Get]] and [[Put]] internal methods.

But, it's all moot, as this is destined to be completely rewritten.

# Axel Rauschmayer (13 years ago)

But, it's all moot, as this is destined to be completely rewritten.

Got it. Thanks!

Axel

# Tom Van Cutsem (13 years ago)

2012/9/27 Allen Wirfs-Brock <allen at wirfs-brock.com>

As usual, at harmony:specification_drafts

Changes include:

  • [...]
  • Roughed in section 15 places holders for Set, Weakmap, Proxy, and the Reflect module. Feedback on overall organization of this material is welcome.

This division looks fine. We'll probably also need the following sections:

  • WeakSet Objects (needed for interaction between proxies and private symbols, but of course much more useful and general than that)
  • The Handler Constructor (as per < harmony:virtual_object_api>,

defining a useful "default proxy handler" that programmers can subclass)

# Allen Wirfs-Brock (13 years ago)

On Oct 1, 2012, at 8:34 AM, Tom Van Cutsem wrote:

  • The Handler Constructor (as per harmony:virtual_object_api, defining a useful "default proxy handler" that programmers can subclass)

I think I'm going to trying to fit all the moving parts of the Proxy mechanism (other than the more general Reflect module) into a single subsection of chapter 15.

# Rick Waldron (13 years ago)

On Mon, Oct 1, 2012 at 8:34 AM, Tom Van Cutsem <tomvc.be at gmail.com> wrote:

Hi Allen,

2012/9/27 Allen Wirfs-Brock <allen at wirfs-brock.com>

As usual, at harmony:specification_drafts

Changes include:

  • [...]
  • Roughed in section 15 places holders for Set, Weakmap, Proxy, and the Reflect module. Feedback on overall organization of this material is welcome.

This division looks fine. We'll probably also need the following sections:

  • WeakSet Objects (needed for interaction between proxies and private symbols, but of course much more useful and general than that)

Tom, I filed a ticket for this last week :)

ecmascript#661

# Tom Van Cutsem (13 years ago)

2012/10/1 Allen Wirfs-Brock <allen at wirfs-brock.com>

I think I'm going to trying to fit all the moving parts of the Proxy mechanism (other than the more general Reflect module) into a single subsection of chapter 15.

That makes sense. From the top of my head, the only other places where proxies intervene substantially in the spec are:

  • the big refactoring of some Object internal methods ([[Get]], [[Put]], [[CanPut]] etc.).
  • built-ins like Object.keys that in ES5 didn't dispatch to a built-in [[Method]] need to either a) test and branch on Proxy arguments explicitly or b) be rewritten to dispatch to a new built-in that proxies then implement differently. I take it you prefer b) (as was done with [[Enumerate]]). I prefer b) as well.
# Allen Wirfs-Brock (13 years ago)

On Oct 1, 2012, at 10:06 AM, Tom Van Cutsem wrote:

2012/10/1 Allen Wirfs-Brock <allen at wirfs-brock.com>

I think I'm going to trying to fit all the moving parts of the Proxy mechanism (other than the more general Reflect module) into a single subsection of chapter 15.

That makes sense. From the top of my head, the only other places where proxies intervene substantially in the spec are:

  • the big refactoring of some Object internal methods ([[Get]], [[Put]], [[CanPut]] etc.).
  • built-ins like Object.keys that in ES5 didn't dispatch to a built-in [[Method]] need to either a) test and branch on Proxy arguments explicitly or b) be rewritten to dispatch to a new built-in that proxies then implement differently. I take it you prefer b) (as was done with [[Enumerate]]). I prefer b) as well.

sounds about right