Re: IndexedDB: undefined parameters

On 10/10/12 6:51 PM, Jonas Sicking wrote:
> FWIW, ES6 is going to treat the undefined value as "not passing a
> parameter" when it comes to functions that have default values.

When there are default values, yes.  But what about cases when there are 
no default values?

Note that openCursor, which I think is where this thread started, does 
NOT define default values for its arguments.  Should it?

(As a side note, the IDL for openCursor is not valid WebIDL, because 
"any?" is not a valid WebIDL type.)

> In anticipation of ES6 formally defining this, WebIDL has already
> switched to this

It certainly hasn't so far, though I agree it may be a good idea to do this.

In fact, WebIDL doesn't even do what you want here with 
[TreatUndefinedAs=Missing].  All that does is that if it's present on an 
argument and all arguments after it, and if all the values passed for 
all those arguments are undefined, then the effective overload used is 
the one with all those arguments omitted.  So if you have this IDL:

   void foo([TreatUndefinedAs=Missing] optional int foo,
            [TreatUndefinedAs=Missing] optional int bar);

and you make this call:

   foo(undefined, 5)

this will behave the same as foo(0, 5).

Basically, TreatUndefinedAs=Missing is meant to let you pretend like 
trailing undefined values don't affect arguments.length, in ES terms.

Think about all this from the point of view of an ES impl of foo() 
above.  How would you represent, in an ES function that expects its 
first argument to be an int and the second argument to be an int but 
makes them optional, the concept of "second int passed, but first not 
passed"?  However you'd do that, that's probably what WebIDL should aim for.

ccing public-script-coord here, because it seems like there's some 
serious lack of clarity about what WebIDL does now and what behavior 
people want out of it.

Note that all this affects openCursor and the like only tangentially, 
because those take an "any" type and hence have to do type introspection 
anyway.  They can define whatever behavior is desired for null or 
undefined or whatnot.

> As for null, the intent was that 'null' would be interpreted as 'not
> defined' and thus the same as undefined. Though this isn't very clear
> in the spec.

It's not just not clear, it's not present at all, as far as I can tell.

-Boris

Received on Thursday, 11 October 2012 01:13:29 UTC