- From: David Dorwin <ddorwin@google.com>
- Date: Fri, 3 Oct 2014 15:41:48 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: Mark Watson <watsonm@netflix.com>, "public-html-media@w3.org" <public-html-media@w3.org>
- Message-ID: <CAHD2rsjptD1zdde_Bpq6ZPqM2v2s8_jSR1+Z67_w4DpFjCp+dQ@mail.gmail.com>
On Thu, Oct 2, 2014 at 12:58 PM, David Dorwin <ddorwin@google.com> wrote: > > On Fri, Sep 26, 2014 at 8:54 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > >> I assume myKeyId is some kinda arbitrary string, right? >> > > myKeyId is probably an ArrayBuffer[View]. (However, see question #4.) I > don't know whether that affects this discussion. > >> >> The best way to do that, as of today's thinking on API design, is to >> create an interface that mimics the ES Map API but doesn't provide any of >> the mutation methods. >> >> That would give you things like: >> >> var mykeystatus = session.keys.get(myKeyId) >> > > The ability to get the status for a known key ID like this seems useful. > >> >> and >> >> for (keyId of session.keys.keys()) // loops over key ids >> >> and >> >> for (keyStatus of session.keys.values()) // loops over key statuses >> > > For any type of iteration (or indexes), applications must not assume the > containers are consistent outside the current synchronous execution. > >> >> The fact that two very different things are being called "keys" here is a >> bit annoying, I agree. :( >> >> You can certainly do this all with Web IDL, though it's a pretty manual >> process to define things like keys() and values(). There are some >> proposals to doing it somewhat automagically via dedicated "make this look >> like a Map" IDL syntax, but nothing concrete there yet. >> > > I was referred to this bug: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=26183 > > Given that there is a general effort to do things like this, this may be > the best direction for us. > See the newly-added maplike declaration feature of WebIDL: http://heycam.github.io/webidl/#idl-maplike > >> The reason to do it that way instead of using direct JS property access >> as you proposed is that this will prevent issues like name collisions with >> various builtin stuff (like methods on the object itself). >> >> Whether this sort of API is best for solving your initial problem, I >> can't tell you, but if it is it's quite possible to create. >> >> -Boris >> > >
Received on Friday, 3 October 2014 22:42:35 UTC