This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22806 - Why special case Date and RegExp in #es-sequence
Summary: Why special case Date and RegExp in #es-sequence
Status: RESOLVED MOVED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebIDL (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Cameron McCormack
QA Contact: public-webapps-bugzilla
URL:
Whiteboard: [v1]
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-25 18:10 UTC by Erik Arvidsson
Modified: 2016-09-08 21:15 UTC (History)
6 users (show)

See Also:


Attachments

Description Erik Arvidsson 2013-07-25 18:10:16 UTC
http://dev.w3.org/2006/webapi/WebIDL/#es-sequence

"Any kind of object except for a native Date object or a native RegExp object"

Why are we special casing these 2? ES5 has a bunch of classes (Error, *Error, Number, Boolean, Function etc) and ES6 has a lot more.
Comment 1 Domenic Denicola 2013-07-25 18:12:59 UTC
+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.
Comment 2 Boris Zbarsky 2013-07-27 00:59:37 UTC
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.
Comment 3 Erik Arvidsson 2013-07-30 19:59:58 UTC
Why not call out all the other ES5 built-ins? Is it because only Date and RegExp have known overloads?
Comment 4 Boris Zbarsky 2013-07-30 20:15:08 UTC
It's because Date and RegExp are built-ins that have corresponding WebIDL types.
Comment 5 Allen Wirfs-Brock 2013-07-30 20:29:09 UTC
(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
Comment 6 Boris Zbarsky 2013-07-30 20:50:14 UTC
For functions, overloading of WebIDL callbacks (which is the WebIDL type for functions) and sequences is well-defined.  See comment 2, please.
Comment 7 Boris Zbarsky 2013-07-30 20:50:43 UTC
And in case it's not clear, I would definitely support removing this restriction.  It sure makes implementation simpler/faster!
Comment 8 Allen Wirfs-Brock 2013-07-30 22:09:09 UTC
(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.
Comment 9 Boris Zbarsky 2013-07-31 01:33:21 UTC
> 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.
Comment 10 Domenic Denicola 2016-09-08 21:15:20 UTC
Since Date has been removed, https://github.com/heycam/webidl/issues/145 now covers this for the remaining case of RegExp. See also https://github.com/heycam/webidl/issues/148.