22806 2013-07-25 18:10:16 +0000 Why special case Date and RegExp in #es-sequence 2016-09-08 21:15:20 +0000 1 1 1 Unclassified WebAppsWG WebIDL unspecified PC All RESOLVED MOVED [v1] P2 normal --- 1 erik.arvidsson cam allen bzbarsky chris d mike public-script-coord public-webapps-bugzilla oldest_to_newest 91286 0 erik.arvidsson 2013-07-25 18:10:16 +0000 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. 91287 1 d 2013-07-25 18:12:59 +0000 +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. 91340 2 bzbarsky 2013-07-27 00:59:37 +0000 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. 91425 3 erik.arvidsson 2013-07-30 19:59:58 +0000 Why not call out all the other ES5 built-ins? Is it because only Date and RegExp have known overloads? 91426 4 bzbarsky 2013-07-30 20:15:08 +0000 It's because Date and RegExp are built-ins that have corresponding WebIDL types. 91429 5 allen 2013-07-30 20:29:09 +0000 (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 91430 6 bzbarsky 2013-07-30 20:50:14 +0000 For functions, overloading of WebIDL callbacks (which is the WebIDL type for functions) and sequences is well-defined. See comment 2, please. 91431 7 bzbarsky 2013-07-30 20:50:43 +0000 And in case it's not clear, I would definitely support removing this restriction. It sure makes implementation simpler/faster! 91433 8 allen 2013-07-30 22:09:09 +0000 (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. 91441 9 bzbarsky 2013-07-31 01:33:21 +0000 > 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. 127351 10 d 2016-09-08 21:15:20 +0000 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.