Re: How to correctly spec sequences requiring an iterable

Boris Zbarsky wrote:
> On 11/15/13 2:02 PM, Boris Zbarsky wrote:
>> Now either jQuery is full of bad API design here, or people actually
>> want APIs like this in some cases...
>
> This thread died after I sent that, apparently.

Threadkiiller! :-P

I heard crickets because people don't like saying it, but there are bad 
API design patterns in jQuery. I know jQuery folks who agree, and who 
have moved to clean up APIs in need of revision, with compatibility 
shimming.

> My current plan in WebIDL is to spec sequence<> as follows, with the 
> incoming value as "val":
>
> 1) If val is not an object, move on to the next union member (or throw
>    an exception if none left).  This allows a union of sequence and
>    string, and is the current behavior of sequences anyway.
> 2) Do iter = Get(val, @@iterator).  ReturnIfAbrupt.
> 3) If the value is not an object or is not callable, move on to the
>    next union member.
> 4) Commit to treating this as a sequence.
> 5) iterator = iter.call(val);
> 6) Walk through with IteratorStep/IteratorValue etc, converting each
>    sequence element before stepping to the next one.
>
> Does anyone see any obvious problems with that other than the 
> (controversial) object check in step 1?

I think it's fine. Primitive string is not String wrapper, even if both 
are iterable and unobservable (in general; definitely in strict mode) 
wrapping means you can use a primitive string as if it were an object.

Because typeof can distinguish, APIs can and will continue to 
distinguish. Is-a-primitive-string and is-iterable must therefore be 
ordered in one way or the other. I do not see why is-iterable must come 
first, always and everywhere -- and indeed it already does not, in 
extant APIs using WebIDL unions, and in jQuery.

Good or bad API design doesn't quite enter into it at this point.

/be

Received on Monday, 18 November 2013 18:06:44 UTC