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

[Bug 26183] make it easier to define an iterator on an interface that iterates over a set of values

From: <bugzilla@jessica.w3.org>
Date: Thu, 02 Oct 2014 04:25:50 +0000
To: public-script-coord@w3.org
Message-ID: <bug-26183-3890-CVns3xjqcw@http.www.w3.org/Bugs/Public/>

--- Comment #18 from Cameron McCormack <cam@mcc.id.au> ---
(In reply to Anne from comment #17)
> That seems nice, but not sufficient for my three multimaps. FormData,
> URLSearchParams, and Headers, all have an associated list of sorts where
> each entry consists of a name and a value.
> I should be able to easily explain what the list is, what the keys/names
> are, and what the values, and then based on that IDL can "generate" keys(),
> values(), and Symbol.iterator behavior.
> Does that make sense? If you disagree I guess I could also define keys(),
> values(), entries() etc. on my own but then it seems I would like some kind
> of hook so I can define these methods to return iterators. (I could even see
> me defining this as some kind of MultiMapIterator mixin that I have
> implemented by each object. Then maybe later it can be uplifted to IDL.)

Yeah, my commit just addresses comment 0.  I agree we should have something
that will auto-generate keys(), entries(), etc.

So I think we need at least:

* a way to declare an interface as having a read only array-like or map-like or
  set-like interface (though I might leave array-like for later), that
  generates entries(), forEach(), get(), has(), keys(), get size, values(), and

* a way to declare an interface as having a read-write map-like or set-like
  (but not array-like) interface, that generates all of the above plus clear(),
  delete(), and set()

And maybe also:

* a way to declare an interface as having a single value iterator that
  generates only entries(), keys(), values(), and @@iterator

* a way to declare an interface as having a pair iterator that generates
  only entries(), keys(), values(), and @@iterator

Syntax for that could be the following, which you use inside an interface:

  // gives you entries(), keys(), values(), @@iterator
  iterable<ScalarValueString, sequence<FormDataEntryValue>>;

  // gives you the above, plus forEach(), get(), has(), get size
  readonly maplike<DOMString, float>;
  readonly setlike<DOMString>;

  // gives you the above, plus clear(), delete() and set()
  maplike<DOMString, float>;

Prose would be used to define the values that are exposed, like with the
#dfn-iterate-a-list-of-values definition I just added.  The behaviour of
entries(), keys(), values(), @@iterator, forEach(), get() and has() would all
be defined automatically based on that list of values.  Prose would be required
to define what happens for clear(), delete() and set().

FormData being a multi-map doesn't really fit with all of the Map object's
methods -- get() is different, for example, as it returns only a single value. 
has() is the same.  And would you want forEach()?  We could have a built-in
multi-map-like declaration, but given there's no MultiMap object in ES to model
the interface after, I'm not certain which methods we'd want to expose there.

So I assume for the moment that you'd just want:

interface FormData {
  // all the existing members
  iterable<ScalarValueString, sequence<FormDataEntryValue>>;

This makes me wonder whether we need the current iterator; declaration, which
allows you to specify the behaviour of @@iterator but nothing else.  Maybe all
the time we want to make an object iterable we also want entries(), keys() and
values() on it too?

You are receiving this mail because:
You are on the CC list for the bug.
Received on Thursday, 2 October 2014 04:25:51 UTC

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