In 15.14.1.1 "MapInitialization",
move step 4 ("If iterable is not undefined ...")
to after step 7 ("If iterable is undefined, return obj."),
and remove the condition (since it's guaranteed true).
I.e., promote the substeps of 4 to top-level steps between 7 and 8.
(Note that you have to convince yourself that step 4.a can't cause
iterable to become undefined.)
If those steps were move, then obj could get observably tagged as an initialized map (by getting a [[MapData]] internal property) before a possible abrupt termination of those steps. It seems better to validate the iterable argument before modifying obj.
in October 26, 2012 release draft
(In reply to comment #1)
> If those steps were move, then obj could get observably tagged as an
> initialized map (by getting a [[MapData]] internal property) before a possible
> abrupt termination of those steps.
Ah, right.
So what I *should* have suggested is:
...
4. If iterable is undefined, then
a. [current step 5]
b. [current step 6]
c. return obj
[current steps 4.a - 4.h]
[current step 5]
[current step 6]
[current step 8]
This has the downside of repeating the current steps 5 and 6:
5. Add a [[MapData]] internal property to obj.
6. Set obj's [[MapData]] internal property to a new empty List.
However, it occurs to me that step 5 is odd: it adds an internal property without setting it. That is, the spec would normally combine those two steps into one:
Add a [[MapData]] internal property to obj with value an empty List.
(or, if that sounds a bit clunky, "... with an empty List as its value".)
So assuming that change, then my suggested refactoring would only repeat a single step, which doesn't seem like much of a drawback.
Ditto all that to the corresponding algorithms in 15.15.1.1 and 15.16.1.1.
Steps 2-3 also need to be moved, since 4a-h are not side effect free, which means it's technically possible to execute steps 5-6 multiple times. Or possible side effects in 4a-h change `obj` to extensible=false and later in steps 5-6 a now no longer extensible `obj` is altered.
How about reviewing the current 23.1.1.1 (the Map constructor) to see if you think all the formal issues have been addressed.
The problem mentioned in comment 4 still applies:
new class extends Map {
constructor() {
let iter = {[Symbol.iterator]: () => {
super();
return [].values();
}};
super(iter);
}
}
That example leads to:
java.lang.AssertionError: Map already initialised
at com.github.anba.es6draft.runtime.objects.collection.MapObject.initialise(MapObject.java:51)
at com.github.anba.es6draft.runtime.objects.collection.MapConstructor.call(MapConstructor.java:103)
at #typein_7.!constructor~1(typein:7)
...
fixed in rev21 editor's draft
fixed in rev21 draft