W3C home > Mailing lists > Public > public-web-intents@w3.org > June 2012

Re: Gallery API draft review request

From: Robin Berjon <robin@berjon.com>
Date: Thu, 21 Jun 2012 00:08:40 +0200
Cc: WebIntents <public-web-intents@w3.org>
Message-Id: <DC197383-B92C-4F70-AD24-56B52697F600@berjon.com>
To: Greg Billock <gbillock@google.com>
On Jun 21, 2012, at 00:02 , Greg Billock wrote:
> 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.

I have no idea as to whether there are implementation limits here. Dictionaries are a fairly recent addition to WebIDL so I wouldn't be surprised if it turned out that they just haven't been used much (rather than having posed an actual problem).

Note that the actual type of the |extras| attribute isn't really "dictionary", there is no such type. I think the closest match is Object. I have very limited knowledge of how this is implemented, but raking my brain I can't see a good reason why it wouldn't be possible for an implementation to have an attribute just be an Object.

Robin Berjon - http://berjon.com/ - @robinberjon
Received on Wednesday, 20 June 2012 22:09:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:14:47 UTC