On Tue, 7 Sep 2010, Darin Fisher wrote:
Based on the ValidityState example, it seems that the members of Flags
should be camelCase then instead of UPPERCASE?
The platform convention, insofar as there is a convention, is that
constants are uppercase, members are camelCase, and interfaces and
On Tue, Sep 7, 2010 at 11:13 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 7 Sep 2010, Darin Fisher wrote:
Based on the ValidityState example, it seems that the members of Flags
should be camelCase then instead of UPPERCASE?
The platform convention, insofar as there is a convention, is that
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
On Tue, Sep 7, 2010 at 12:41 AM, Kinuko Yasuda kin...@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
On Tue, Sep 7, 2010 at 6:07 PM, Eric Uhrhane er...@google.com wrote:
On Tue, Sep 7, 2010 at 12:41 AM, Kinuko Yasuda kin...@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 /
On Tue, 7 Sep 2010, Adam Barth wrote:
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
On Tue, Sep 7, 2010 at 8:41 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 7 Sep 2010, Adam Barth wrote:
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
