W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2014

[Bug 27008] "Initializing objects from iterables" needs syntax

From: <bugzilla@jessica.w3.org>
Date: Thu, 09 Oct 2014 16:27:20 +0000
To: public-script-coord@w3.org
Message-ID: <bug-27008-3890-Dj40MWvCIV@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27008

--- Comment #9 from Domenic Denicola <domenic@domenicdenicola.com> ---
ES6 maps take arbitrary objects as keys, so it needs to be [["H", "V"], ["H2",
"V2"]] so that instead of "H" you can use `{ foo: "bar" }` or something. This
seems important in the general case for headers so you can do [["H1", "V1a"],
"H1", "V1b"]].

It makes sense to allow the Headers constructor to be overloaded with a
(non-iterable) object as well for the less-general case. Nothing in ES does
this but you could follow a pretty similar pattern. In JS it'd probably be

```js
function useHeaders(headersInit) {
  Object.keys(headersInit).forEach(key => this.set(key, headersInit[key]);
}
```

Now that I look at this more closely I think I see why you desire syntax. Here
is my thought on the ideal way for it to work, without any compromises like
copying everything into a sequence and then performing the algorithm:

- We would add an "initializing objects from open-ended dictionaries" too,
roughly following the above JS algorithm.
- We would modify the "add map elements from an iterable" to return a
success/failure signal.
- You'd use some sort of syntax (WebIDL gurus make this better, and see below
for intended semantics)

  [Constructor(optional (Headers or MapInitIterable or OpenEndedDictionary)
init)]

- Your constructor algorithm would contain prose to the effect of:

  - "In the MapInitIterable case, [add map elements from iterable] _init_ to
**this** with adder method `"append"`"
  - "In the OpenEndedDictionary case, [add map elements from open-ended
dictionary] _init_ to **this** with adder method `"append"`.

  (you could use "set" for the latter instead of "append"; it doesn't matter.)

- The intended semantics of the constructor definition are then that it tries
in sequence: (1) if it's undefined, do nothing. Otherwise, (2) check for the
Headers brand, and if present, use that; (3) if not, try the add map elements
from iterable algorithm; (4) if that returns a failure signal, try the add map
elements from open-ended dictionary algorithm; (5) if that returns a failure
signal, throw a TypeError.

Note how there is no type argument to OpenEndedDictionary since calling
`this.append` does the conversion at that stage.

Also note that in practice you could omit the Headers from the constructor
since Headers is already iterable. It would be observably different in that if
someone had instrumented Headers.prototype[Symbol.iterator] or
Headers.prototype.append they would not get their instrumentation triggered in
the brand-check case, I assume, since that assimilation would not happen
through public APIs but instead by pulling the private state out of the other
Headers instance and plopping it into `this`.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Thursday, 9 October 2014 16:27:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:23 UTC