Re: [IndexedDB] Numeric constants vs enumerated strings

Oh, but I should add that I think it's fine for implementations to
keep support for the numbers for a transition period if they so
desire.

/ Jonas

On Thu, Feb 23, 2012 at 1:27 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> Yes! I would love to make this change.
>
> This is my main peeve with the API as it stands.
>
> I even think that implementations could remove support for the numbers
> by keeping the constants but have them defined to return string
> values. I.e.
>
> db.transaction(["store"], IDBTransaction.READ_WRITE);
>
> would continue to work and is the usage pattern that I've seen in all
> code that I've looked at.
>
> Yes, the read-only attributes would change, but like Joshua I've never
> seen code use those so far.
>
> / Jonas
>
> On Wed, Feb 22, 2012 at 6:02 PM, Joshua Bell <jsbell@chromium.org> wrote:
>> On Wed, Feb 22, 2012 at 4:57 AM, Odin Hørthe Omdal <odinho@opera.com> wrote:
>>>
>>> I propose that we change the numeric constants to enumerated strings in
>>> the IndexedDB spec.
>>>
>>> Reasoning is echoing the reasoning that came up for WebRTC:
>>>
>>> <http://lists.w3.org/Archives/Public/public-script-coord/2012JanMar/0166.html>
>>
>> ...
>>>
>>>
>>> So. What do you think? :-)
>>
>>
>> I don't have strong feelings about this proposal either way. Ignoring the
>> *Sync APIs, this would involve changing:
>>
>> Methods:
>> IDBDatabase.transaction() - mode
>> IDBObjectStore.openCursor() - direction
>> IDBIndex.openCursor() - direction
>> IDBIndex.openKeyCursor() - direction
>>
>> Attributes (read-only):
>> IDBRequest.readyState
>> IDBCursor.direction
>> IDBTransaction.mode
>>
>> During a transition period, implementations of the methods could take either
>> a number or a string. The attributes are not so easy; it would be a breaking
>> change. Fortunately, those attributes are generally informative rather than
>> critical for app logic (at least, in the code I've seen), so the impact is
>> likely to be low. JS authors could check for both values (e.g.
>> request.readyState === IDBRequest.DONE || request.readyState === "done"),
>> just as authors must work around implementation differences today. So IMHO
>> it's plausible to make this change with little impact.
>>

Received on Thursday, 23 February 2012 00:29:31 UTC