W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

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

From: Kris Zyp <kris@sitepen.com>
Date: Thu, 10 Jun 2010 10:48:33 -0600
Message-ID: <4C111761.3000300@sitepen.com>
To: WebApps WG <public-webapps@w3.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 


On 2/2/2010 12:48 PM, Kris Zyp wrote:
>
>
> 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)).
>

I see that in the trunk version of the spec [1] that delete() was
changed to remove(). I thought we had established that there is no
reason to make this change. Is anyone seriously expecting to have an
implementation prior to or without ES5's contextually unreserved
keywords? I would greatly prefer delete(), as it is much more
consistent with standard DB and REST terminology.

[1]
http://dvcs.w3.org/hg/IndexedDB/raw-file/d697d377f9ac/Overview.html#object-store-sync
- -- 
Thanks,
Kris

- -- 
Kris Zyp
SitePen
(503) 806-1841
http://sitepen.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkwRF2EACgkQ9VpNnHc4zAyFgwCeIhWGFQFXCrGdhCqSg43YLEur
mRcAn0hPK/EvQT17Oeg1EfT2VHp9goNF
=UO8O
-----END PGP SIGNATURE-----
Received on Thursday, 10 June 2010 16:49:16 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:39 GMT