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

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26183

--- 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
  @@iterator

* 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>>;
  iterable<Node>;

  // 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>;
  setlike<FontFace>;

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