W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

[IndexeddDB] Definitions of "valid key" and key comparison need to be tightened up

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 09 Oct 2012 14:33:25 -0400
Message-ID: <50746DF5.5020609@mit.edu>
To: public-webapps@w3.org
I was just looking at 
and I had some concerns about it.  Specifically:

1)  The definition of "valid key" mentions "Array JavaScript objects" 
without making it clear what that means.  Does that mean that the 
[[Class]] is Array?  That the prototype is Array.prototype?  Something else?

2)  The text about "float" makes no sense, because "float" in WebIDL 
can't be infinite.  Presumably what's meant here is "unrestricted float"?

3)  It's not clear what the algorithm for determining whether a key is 
valid in the Array case is.  Is the following key valid:

   var obj = [];
   Object.defineProperty(foo, "0", { value: 1 });

?  What about this one:

   function getItem() {
     return 1;
   var obj = [];
   Object.defineProperty(foo, "0", { get: getItem });

?  What about this one:

   var obj = [];
   function getItem() {
     if (Math.random() < 0.99) {
       return 1;
     } else {
       return obj;
   Object.defineProperty(foo, "0", { get: getItem });

Note that for all of these arrays "every item in the array is defined".

4)  The thing about float and DOMString is a bit confusing to me.  Seems 
like the intent is that "NaN" is a valid key, right?  And that "5" and 5 
are different keys?  So if you're using keys that came from cookies or 
form controls or whatnot you have to be very careful to convert from 
string to numeric representation as needed?  Note that generally in 
WebIDL string and float are not treated as distinguishable, for 
precisely these reasons...  Also note that there is no way to ask 
whether something "is" a DOMString or a WebIDL "float".  All WebIDL 
provides is a way to _convert_ a given value to one of those types.  Any 
sort of asking what type something "is" for an "any" value sort of needs 
to happen on ECMAScript types, not WebIDL ones.  As a particularly 
interesting example, is this a valid key:

   var key = { toString: function() { return "foo"; },
               valueOf: function() { return 5; } };

?  This is convertible to both WebIDL DOMString (giving "foo") and 
WebIDL float (giving 5).  So it's not clear to me exactly how a UA is 
supposed to decide whether a key "is" of "type" DOMString or float.

5)  It's not clear what meaning of "Date" is being used here.  Again, is 
it some particular [[Class]] or is it some particular prototype, or 
something else?

6)  The comparison algorithm for arrays needs to say whether A[i] or 
B[i] is evaluated first, if arrays with indexed accessor properties are 
valid keys, because the get can have side effects.

7)  Similarly, if arrays with indexed accessor properties are valid 
keys, the recursive calls in steps 4 and 5 of the comparison algorithm 
need to explicitly say which of A[i] and B[i] become the new A and B. 
And I suspect that actually the algorithm doesn't mean to invoke itself 
twice recursively in this situation anyway...  Unfortunately, if arrays 
with indexed accessor properties are valid keys UAs can't combine the 
two recursive calls into one call in case when A[i] and B[i] are in fact 
equal arrays.

I suspect the right answer to #3, #6, #7, is to require that all the 
properties 0,...length-1 on the array be own value properties in a valid 
Array key, for what it's worth.

Received on Tuesday, 9 October 2012 18:33:55 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:49 UTC