[webkit-dev] Optional parameter in IDL and undefined JS value

[Jian Li]

Please see inline for the reply from the spec author Arun about your
questions.

Arun has updated Blob.slice in the File API spec to explicitly illustrate
the case for optional end parameter.

If the optional end parameter is not used as a parameter when making this
call, let relativeEnd be size.


For undefined value being passed to optional numeric parameter, should we
consider following ECMA-262 (referred from Web IDL) that defines the
conversion of undefined to "NaN" (see Table 12 in Section 9.3)?


On Fri, Apr 22, 2011 at 3:00 PM, Geoffrey Garen <ggaren at apple.com> wrote:

>  I would suggest updating the specification for Blob.slice() so that it
>> doesn't expect passing "undefined" for the second argument to have
>> identical behavior to not passing the argument at all. The "subarray"
>> method in the Typed Array spec [1], which has similar behavior to
>> slice(), doesn't mention the undefined value.
>>
>
> I am afraid that this suggested change might not be preferred since we're
> trying to mimic the behavior of Blob.slice to Array.slice and Array.slice
> does allow passing undefined and treat it as omitting the value.
>
>
> Jian,
>
> Can you clarify why we want Blob.slice to mimic Array.prototype.slice in
> this strange argument quirk?
>
> Let me suggest three reasons why we don't want Blob.slice to mimic
> Array.prototype.slice in this strange argument quirk:
>
> 1. Legacy argument quirks exist for legacy compatibility and nothing else.
> Since Blobs have no legacy requirements, they should not re-introduce the
> mistakes of JavaScript past. There are many legacy argument quirks in
> JavaScript. They often confuse programmers, rather than enabling them. For
> example, new Array(x) creates an array with ToInteger(x) elements in it,
> while new Array(x, y) creates an array with 2 elements in it, x and y. Would
> you mimic that quirk in Blobs if you could?
>

(From Arun): Can't argue with his intent in saying this :-).  But, WebIDL
takes care of any calls that ECMA-262 makes w.r.t. numerical arguments (e.g.
there is a ToNumber call presumed for long long arguments), *and* we can't
really do calls of the sort new Blob(x).  Rather, we go via Blob.slice( ) or
BlobBuilder calls.g

>
> 2. A Blob is not an Array. Blobs are incompatible with all other Array
> semantics. They don't have a length property. They don't support bracket
> access. They don't support destructive modification. If Blobs were like
> Arrays, you could just use Array.prototype.slice to slice a Blob. But you
> can't, because they're not alike at all.
>

(From Arun): Blobs are more like Strings -- so I agree with the above.  In
fact, I'm worried about our use of some Array semantics w.r.t. Blob.slice,
but I'm reassured by the fact that byte-order semantics for the "start"
argument to a Blob.slice call matches character-order semantics for the
"start" argument to a String.slice call.  I wonder if there are any other
gotchas here?

>
> 3. Your specification doesn't actually conform to the exact semantics of
> all the argument quirks of Array.prototype.slice. There are a number of
> other quirks that you have left out because they are strange and you are not
> familiar with them. I will leave it as a thought experiment for you to go
> and find all the other quirks of Array.prototype.slice that you have missed.
> While you are seeking them out, you can meditate on whether you are making
> your API better or worse.
>

(From Arun): Hah!  He makes the point strongly here, but he isn't wrong.
I've spent a while reading ECMA-262.  Honestly, Blob is the first "host
object" that introduces a slice method (to the best of my knowledge) and
WebIDL constructs aren't too close to ECMA-262 constructs.


>
> Geoff
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110425/63650482/attachment.html>