Re: IndexedDB: Syntax for specifying persistent/temporary storage

On Fri, Dec 6, 2013 at 11:09 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 12/6/13 1:29 PM, Joshua Bell wrote:
>
>>    // Throws TypeError on older implementations since Dictionary won't
>> coerce to Number (?)
>>
>
> Sure it will.  It'll do ToNumber() and probably end up NaN (which becomes
> 0 as an unsigned long long) unless your object has a valueOf method that
> returns something interesting.
>
>
Whoops - my brain was conflating distinguishable with coercable, and then I
fell into the special case below when testing...


>
>  I don't think overloading has many proponents at the moment, though.
>>
>
> Sure; in practice this would be done as a union type, not overloading.
> That still has the same "how do I tell?" issue, of course.
>
>
>  other options are a different method name, or passing |undefined| as the
>> version, neither of which are great. Allowing null/undefined/0/falsy to
>> mean "current version" wouldn't be too terrible, though, and isn't a
>> compat concern since it explicitly throws today.
>>
>
> It sure doesn't.  null and 0 are perfectly fine values for an unsigned
> long long (null becomes 0 after ToNumber()).


This behavior is specified in prose, not IDL:

https://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#widl-IDBFactory-open-IDBOpenDBRequest-DOMString-name-unsigned-long-long-version

"If the value of version is 0 (zero), the implementation must throw a
TypeError."


>  undefined is treated as not passed.


... and we could default to 0 here, if we went down this path.

Upshot is that falsy throws in implementations today due to unsigned long
long coercion to 0, and the explicit case in the IDB spec. Conveniently,
this would throw for objects as dictionaries per Boris' comments above
(unless someone is trying to confuse themselves with a valueOf method on a
dict...)



>
>
> -Boris
>
>