- From: Adam Barth <w3c@adambarth.com>
- Date: Tue, 7 Sep 2010 18:27:21 -0700
- To: Eric Uhrhane <ericu@google.com>
- Cc: Kinuko Yasuda <kinuko@chromium.org>, Web Applications Working Group WG <public-webapps@w3.org>, Robin Berjon <robin@berjon.com>
On Tue, Sep 7, 2010 at 6:07 PM, Eric Uhrhane <ericu@google.com> wrote:
> On Tue, Sep 7, 2010 at 12:41 AM, Kinuko Yasuda <kinuko@chromium.org> wrote:
>> Hi Eric,
>> (re-sending from the correct address)
>>
>> I've been re-reading the spec and started wondering if we really want to
>> have a new interface / javascript object for Flags.
>> The Flags interface is used to specify two behavioral options (CREATE and
>> EXCLUSIVE) for DirectoryEntry.getFile and getDirectory and defined as
>> following:
>>
>> 4.2. The Flags Interface
>> http://dev.w3.org/2009/dap/file-system/file-dir-sys.html#the-flags-interface
>>
>> interface Metadata {
>>
>> attribute boolean CREATE;
>>
>> attribute boolean EXCLUSIVE;
>>
>> };
>>
>> (by the way I assumed you meant Flags but not Metadata.)
>>
>> As the example code shows (4.2.2 Examples), each Flags object will likely be
>> used as a 'one-time' object just to specify the behavior per each
>> getFile/getDirectory. If that's the case, isn't it simpler/easier to use a
>> bitfield and use single unsigned int parameter for the flags [proposal 1]?
>
> That was my original proposal; see the very brief discussion at
> http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0036.html.
> Robin [+CC] suggested we switch to an interface object. I think the
> current form is nicely explicit and easy to understand and use. The
> bitflags are traditional in POSIX, but not very JavaScript-ish.
>
>> Or if we're not going to add more options it might be also good to simply
>> use two separate boolean parameters [proposal 2].
>
> I don't like this. The more parameters you have, the harder the
> methods get to use. This mechanism would make expanding the API quite
> messy. Also, having two boolean parameters right next to each other
> is error-prone.
>
> I think that ORing together bits is better than adding more
> parameters, and I think the current proposal is cleaner than that.
> But I'm open to debate, of course.
I think the bitfield approach is better. The current approach doesn't
work very well in strongly typed languages. Although we might think
that these APIs will be used most-often from JavaScript, these APIs
are language neutral and should work in a variety of settings (e.g.,
as part of the NPAPI). Baking in assumptions that APIs are used by
dynamically typed language isn't good for the web platform in the long
term.
Adam
Received on Wednesday, 8 September 2010 01:29:24 UTC