Re: [IndexedDB] Numeric constants vs enumerated strings

On Thu, 23 Feb 2012 01:27:27 +0100, 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.

Cool! :D

> 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.

Ah, that is a very smart idea.


We just had the break of open() with upgradeneeded instead of setVersion.  
That's a much bigger break, and if most of us get this in with the same  
change - it can just slip nicely in. The code would have to change anyway.  
So I think it's not too hard to remove the constants as well. It's  
obviously a bit different for Mozilla, since they've shipped their  
setVersion killer already, but generally Mozilla is not afraid of changing  
stuff if they want to (and it doesn't hurt too much, which IMHO it won't  
in this case, sync XHR + CORS is much more painful :P).

The few people who code directly to nightly versions will be used to  
changing their code anyway.


Keep supporting the numbers is OK, but a bit strange, given the above  
reasons.  As long as it's not possible to rely on the numbers, I hope that  
developers won't use it anyway, and it'll slowly become obsolete. Then it  
can be very easily removed again. Although skipping that dance is of  
course even better ;-)


To be honest, I think authors will use the enumerated strings - so if some  
implementations do some backwards compat stuff, it'll hopefully become  
obsolete.
-- 
Odin Hørthe Omdal · Core QA, Opera Software · http://opera.com /

Received on Thursday, 23 February 2012 09:48:33 UTC