- From: Greg Billock <gbillock@google.com>
- Date: Wed, 20 Jun 2012 15:02:47 -0700
- To: Robin Berjon <robin@berjon.com>
- Cc: WebIntents <public-web-intents@w3.org>
On Wed, Jun 20, 2012 at 3:58 AM, Robin Berjon <robin@berjon.com> wrote: > On May 22, 2012, at 20:52 , Greg Billock wrote: >> One piece of feedback we've gotten on the API is that we should be >> able to enumerate the extra data fields (i.e. returning a dictionary >> there instead of the getExtra() function). My concern about that is >> that it's a bit ambiguous how that relates to Javascript, and that's >> why we don't see APIs use that pattern. Is there a good way around >> that difficulty? > > I've been looking at this again and it made me wonder: is there a reason why this is exposed as getExtra(key) rather than simply having a readonly attribute any extras that would expose the whole thing as a dictionary? I may be missing something, but that would seem to give us good JS integration, enumeration, etc. free. What were the concerns that led to using an accessor here? Exposing a dictionary sounds good to me. Retracing my steps, what I saw looking for analogs was that exposing a dictionary attribute looks like it's not done. There's something close in IndexedDB, but it looks like in the webkit IDL it's limited to a specific whitelist of types. Is there another example of an exposed dictionary like this I can base it off of? My recollection is that it ends up being an implementation problem because of the interaction with the JS code.
Received on Wednesday, 20 June 2012 22:03:16 UTC