[Bug 22806] Why special case Date and RegExp in #es-sequence

# bugzilla at jessica.w3.org (3 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22806

Domenic Denicola domenic@domenicdenicola.com changed:

       What    |Removed                     |Added

             CC|                            |domenic@domenicdenicola.com

--- Comment #1 from Domenic Denicola domenic@domenicdenicola.com --- +1. This should work:

var arrayLike = new Date(); arrayLike.length = 2; arrayLike[0] = "foo"; arrayLike[1] = "bar";

It's accepted by all ES built-ins.

Contact us to advertise here
# bugzilla at jessica.w3.org (3 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22806

--- Comment #2 from Boris Zbarsky bzbarsky@mit.edu ---

The main issues here are dealing with unions/overloads and whether the types are distinguishable (so that you can do things like (Date or sequence<Date>)).

We can probably just use the same "pick an order" approach we do elsewhere in overload resolution at this point.

# bugzilla at jessica.w3.org (3 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22806

--- Comment #3 from Erik Arvidsson arv@chromium.org ---

Why not call out all the other ES5 built-ins? Is it because only Date and RegExp have known overloads?

# bugzilla at jessica.w3.org (3 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22806

--- Comment #4 from Boris Zbarsky bzbarsky@mit.edu ---

It's because Date and RegExp are built-ins that have corresponding WebIDL types.

# bugzilla at jessica.w3.org (3 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22806

Allen Wirfs-Brock allen@wirfs-brock.com changed:

       What    |Removed                     |Added

             CC|                            |allen@wirfs-brock.com

--- Comment #5 from Allen Wirfs-Brock allen@wirfs-brock.com --- (In reply to comment #4)

It's because Date and RegExp are built-ins that have corresponding WebIDL types.

But why is that relevant? Why is it ok to try to convert a function to a sequence<T> but you won't allow the same conversion for RegExp?

See completely arbitrary

# bugzilla at jessica.w3.org (3 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22806

--- Comment #6 from Boris Zbarsky bzbarsky@mit.edu ---

For functions, overloading of WebIDL callbacks (which is the WebIDL type for functions) and sequences is well-defined. See comment 2, please.

# bugzilla at jessica.w3.org (3 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22806

--- Comment #7 from Boris Zbarsky bzbarsky@mit.edu ---

And in case it's not clear, I would definitely support removing this restriction. It sure makes implementation simpler/faster!

# bugzilla at jessica.w3.org (3 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22806

--- Comment #8 from Allen Wirfs-Brock allen@wirfs-brock.com --- (In reply to comment #6)

For functions, overloading of WebIDL callbacks (which is the WebIDL type for functions) and sequences is well-defined. See comment 2, please.

Oh, I get it now, you have existing API's that are overloaded with X or sequence<X> where X may only be Date or RegExp. Any object that isn't either a

Date or RegExp is treated as an array-like object.

Given how problematic is to make a scalar vs array-like determination for general JS objects, I'll argue that it is very poor design for a JS facing API to have such a overloading. You should forbid this in all new APIs.

You're stuck with the existing APIs that do this, but there is no reason you need to enshrine the ability to make such overloads in WebIDL. It would be better to describe the existing APIs using prose and avoid expose a WebIDL that future API designer might use.

# bugzilla at jessica.w3.org (3 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22806

--- Comment #9 from Boris Zbarsky bzbarsky@mit.edu ---

you have existing API's that are overloaded with X or sequence<X> where X may only be Date or RegExp.

More precisely, WebIDL allows such APIs. I rather hope no one in practice is doing that so far with Date and RegExp, though people certainly do it with Node and Touch and so forth from what I've seen...

Given how problematic is to make a scalar vs array-like determination for general JS objects

For most of the things above, including Date and RegExp, it's not too bad: you check whether the object is a Date or RegExp instance (or Node, whatever) and if not, treat it as an arraylike.

But yes, I think the current API best practice for things like that is to use variadics and assume that people who have an array will use spread operators or .apply...

It would be better to describe the existing APIs using prose

Given past history, I do not trust either spec authors or the average implementor to get this approach right. The nice thing with IDL is that it needs to be implemented once per browser, by someone who knows what they're doing, and then it just works.

I would much prefer having IDL features explicitly marked as deprecated or legacy or whatnot than forcing people to write/implement prose, with all the ensuing problems.

In any case, that's starting to get a bit afield from this bug.

# bugzilla at jessica.w3.org (3 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22806

Cameron McCormack cam@mcc.id.au changed:

       What    |Removed                     |Added

     Whiteboard|                            |[v1]
# bugzilla at jessica.w3.org (a day ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=22806

Domenic Denicola d@domenic.me changed:

       What    |Removed                     |Added

     Resolution|---                         |MOVED
         Status|NEW                         |RESOLVED

--- Comment #10 from Domenic Denicola d@domenic.me ---

Since Date has been removed, heycam/webidl#145 now covers this for the remaining case of RegExp. See also heycam/webidl#148.

Want more features?

Request early access to our private beta of readable email premium.