Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2

Hash: SHA1

On 2/1/2010 8:17 PM, Pablo Castro wrote:
> [snip]

>> the existence of currentTransaction in the same class).
>> "beginTransaction" would capture semantics more accurately. b.
>> ObjectStoreSync.delete: delete is a Javascript keyword, can we
>> use "remove" instead?
> I'd prefer to keep both of these as is. Since commit and abort are
> part of the transaction interface, using transaction() to denote
> the transaction creator seems brief and appropriate. As far as
> ObjectStoreSync.delete, most JS engines have or should be
> contextually reserving "delete". I certainly prefer delete in
> preserving the familiarity of REST terminology.
> [PC] I understand the term familiarity aspect, but this seems to be
> something that would just cause trouble. From a quick check with
> the browsers I had at hand, both IE8 and Safari 4 reject scripts
> where you try to add a method called ?delete? to an object?s
> prototype. Natively-implemented objects may be able to work-around
> this but I see no reason to push it. remove()  is probably equally
> intuitive. Note that the method ?continue? on async cursors are
> likely to have the same issue as continue is also a Javascript
> keyword.

You can't use member access syntax in IE8 and Safari 4 because they
only implement EcmaScript3. But obviously, these aren't the target
versions, the future versions would be the target of this spec. ES5
specifically contextually unreserves keywords, so obj.delete(id) is
perfectly valid syntax for all target browser versions. ES5 predates
Indexed DB API, so it doesn't make any sense to design around an
outdated EcmaScript behavior (also it is still perfectly possible to
set/call the delete property in ES3, you do so with object["delete"](id)).

- -- 
Kris Zyp
(503) 806-1841
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -

Received on Tuesday, 2 February 2010 19:49:52 UTC