RE: Web IDL/ECMA Script Impedence Mismatch: Overloading

I notice that the ECMAScript 5 spec uses a bracket notation, which essentially equates to the 'optional' keyword in WebIDL, e.g., Array.prototype.reduce( callbackfn [, initialValue] )

Are there any native ES methods that might be expressed as a union type?

In general, I'd like to see the operator overloading and its overload resolution algorithm go away. Internally, IE's language for describing properties does not use overloading, and it gets by  with only an 'optional', variadic, and default value indicators.

The default value case really helps with specifying e.g., window.open:
{ ...
WindowProxy open([msDefaultValue=""] in DOMString url, [msDefaultValue=""] in optional DOMString target, [msDefaultValue=""] in optional DOMString features, [msDefaultValue=false] in optional boolean replace);
...
}

-Travis

From: public-script-coord-request@w3.org [mailto:public-script-coord-request@w3.org] On Behalf Of Allen Wirfs-Brock
Sent: Saturday, October 03, 2009 11:47 AM
To: public-script-coord@w3.org
Subject: Web IDL/ECMA Script Impedence Mismatch: Overloading

Web IDL/ECMAScript Impedance Mismatch: Overloading
Allen Wirfs-Brock
Microsoft

There seems to be broad agreement that the primary usage language of interest for web/browser APIs is ECMAScript.  There are scenarios for the use of other languages such as Java but ECMAScript usage in web content dominates all other languages combined.  ECMAScript is the only language whose support is pragmatically mandatory within a modern browser.  Web IDL is intended to be an language independent interface description language but given the wide variety syntax and semantics of real programming language it is reasonable to expect that Web IDL will have a closer "impedance match" with some languages or families of languages than it will with others. What is surprising, given ECMAScript's role in the browser, is the high  Impedance  mismatch between the current Web IDL definition and the ECMAScript language.  (One way to measure the impedance mismatch is by the complexity of the language binding specification.  In the current Web IDL draft approximately 58 pages are required to define the Web IDL to ECMAScript binding while only 19 pages are required for the Java binding.)

In the rest of this note I address two interrelated design points of Web IDL that are significant parts of this problem and how they might be changed in a way that would allow Web IDL to be more appropriate for describing APIs that are primarily accessed from ECMAScript code. There are other significant and unnecessary impedance mismatches between Web IDL and ECMAScript that should also be addressed in other notes.

As a starting point, let's consider operation (ie, method/function) overloading. Overloading is a common characteristic of statically typed object languages. Such language lack the concept of polymorphic function parameters and hence support passing different types of arguments to a commonly named operation by discriminating among multiple like-named functions based upon the statically determinable types of the arguments presented at each call site.  This discrimination is performed via a complex overload resolution algorithm   but because the algorithm depends entirely upon statically available type information it can be performed at "compile time" and introduces no runtime overhead. Dynamically typed languages such a ECMAScript fully support polymorphic function parameters and hence have no need for this style of overloading.  Instead, individual functions that support polymorphic parameters perform situationally appropriate type discrimination based upon the actual values passed on each function invocation.  No complex overload resolution is ever performed.

Because ECMAScript is the language most widely used with Web IDL it might be reasonable to expect that Web IDL would have chosen to handle polymorphic parameters in a manner that most naturally and efficiently maps to ECMAScript.  It does not. Instead it adopts a Java-like static overloading model and then in the Web IDL to ECMAScript binding introduces a complex overload resolution algorithm that must be invoked dynamically as part of  every actual call (see Web IDL  4.5.6 and 3.3.5).  In addition, since neither ECMAScript or the WebIDL to ECMAScript binding provides any way to compose a overload resolution set out of actually ECMAScript functions this is another case where Web IDL makes it impossible to actually implement its interfaces using native ECMAScript functions and objects.

Overall, the current Web IDL approach seems like the inverse of the ideal approach to this problem.  A more natural approach would be for Web IDL to natively support polymorphic parameter specifications and to make the concept of function overloading and  overload resolution a part of the Web IDL to Java  binding (or more generally to provide a generic Web IDL to "java-like" languages binding).  This would permit Web IDL operations to be actually implemented using native ECMAScript functions, move non-essential complexity to the language bindings that actually needs it, and has the advantage that it entails no runtime overhead for either ECMAScript or Java (because static over loading is already an inherent characteristic of that class of language).

So, what would be needed to covert Web IDL from using overloading to using polymorphic parameter specifications?  Consider the following hypothetical interface specification:

interface StreamOutput {
   void write (in short fileNumber, in DOMString text);  //legacy version
   void write (in FileDescriptor fd, in DOMString text);   //modern version
}

Without overloads, how might such an interface  be expressed in Web IDL?  By introducing the concept of union types:

interface StreamOutput {
   void write (in short fileNumber | FileDescriptor fd, in DOMString text);
}

Which says that the first argument can be either a short or a FileDescriptor object.  This could be made more concise using a typedef:

typedef  (short | FileDescriptor) FD;
interface StreamOutput {
   void write (in FD  fd, in DOMString text);
}

Each occurrence of a union type in a parameter position defines a polymorphic parameter.  The language binding for ECMAScript would require no special treatment for such polymorphic parameters.  At runtime, any value could be passed and the function internally controls its behavior based upon its normal internal interrogation of the actual arguments. The language binding for Java would specify that polymorphic parameters introduce statically overloaded alternative functions that are selected according to the overload resolution rules of the Java language.

Once union types are introduced then Web IDL can be simplified in other ways.  For example, Nullable Types are currently needed because Java-like language have no way to express the concept that a particular value may be either null or a primitive value (something that naturally occurs in ECMAScript and other dynamically typed language).  If union types are used then Nullable types can be modeled as a simply union type:

typedef (Null | long) NullableLong;  //assume Null is the type consisting solely of the special value null

Normal overloading could then be used in the Java  binding to discriminate the null case or alternatively the Java  binding could continue to require that the Java user of such APIs to insert explicit conversion expressions to handle such arguments.

In summary, operation overloading should not be part of the core definition of Web IDL.  Instead it should be made part of the language binding for those static language that require its complexity.  Removing overloading and replacing it with polymorphic parameters based upon union types provides an interface description is that more natural for the majoityr of web developers who program in ECMAScript, allows Web IDL operations to be implemented using native ECMAScript objects, introduces no addition runtime overhead for ECMAScript, all  while preserving the ability the realize such interfaces using statically typed languages such as Java.