RE: [IndexedDB] Passing an empty array to IDBDatabase.transaction

On Monday, October 17, 2011 9:14 PM, Cameron McCormack wrote:
> On 17/10/11 7:19 PM, Jonas Sicking wrote:
> > I sort of like the short-cut since it seems like a very common case
> > for web developers to want to create a transaction which only uses a
> > single objectStore.
> >
> > But I agree it's not a huge win for developers as far as typing goes
> > (two characters).
> >
> > I *think* we can move the validation into the IDL binding these days.
> > Something like:
> >
> > interface IDBDatabase {
> >    ...
> >    transaction(DOMStringList storeNames, optional unsigned short mode);
> >    transaction(DOMString[] storeNames, optional unsigned short mode);
> >    transaction(DOMString storeNames, optional unsigned short mode);
> >    ...
> > }
> >
> > The WebSocket constructor does something similar.
> >
> > cc'ing Cameron to confirm that this is valid. It *might* even be the
> > case that DOMStringList passes as a DOMString[]?
> 
> The above IDL is valid (assuming you stick "void" before the function names).
> Although DOMStringList is array like enough to work if you are not
> overloading based on that argument (it has a .length and array index
> properties), in this case because the function call is only distinguished based
> on the first argument you will need those separate declarations.
> 
> You can see what happens when a value is passed as that first parameter
> here:
> 
> http://dev.w3.org/2006/webapi/WebIDL/#dfn-overload-resolution-algorithm

> 
> If it's a DOMStringList object, since that is an interface type, it will definitely
> select the first overload.  And if you pass an Array object or a platform array
> object, then the second overload will be selected.
> 

After discussing this with some folks on our side, this change makes sense to us.  
There seem to be clear advantages at providing these overloads.
I'm guessing we want to make this change to the webIDL of IDBDatabase, correct?

Israel

Received on Tuesday, 25 October 2011 00:29:25 UTC