Understanding Generic Functions

[Lars Hansen]

> -----Original Message-----
> From: es4-discuss-bounces at mozilla.org 
> [mailto:es4-discuss-bounces at mozilla.org] On Behalf Of John Resig
> Sent: 15. november 2007 02:27
> 
> Generic functions are used like this:
> 
> generic function a(b);
> generic function a(b:int){}
> generic function a(b:string){}

Yes.

> Generics offer a point upon which future functions can be 
> bound, like for operator overloading:
> 
> class Foo!{}
> 
> generic intrinsic function +(a:string, b:Foo){} 
> generic intrinsic function +(a:Foo, b:string){} 
> generic intrinsic function +(a:Foo, b:Foo){}

Yes.

> So that's all well-and-good. Now, where I making an 
> assumption is that it's not possible to do the following:
> 
> generic function a(b);
> generic function a(b:int){}
> generic function a(b:string){}
> 
> generic function a(b,c);
> generic function a(b:string, c:int){}

An early proposal had this.  It became complicated.  See below.

> also, it's not clear if you can use generics for constructors 
> - so I'm assuming that that's also not possible:
> 
> class Foo {
>   generic function Foo(b);
>   generic function Foo(b:int){}
>   generic function Foo(b:string){}
> }

At the moment that is true, but there's no reason I'm aware of why that
restriction can't be lifted, apart from issues of having to use the
"settings" (the initializer list preceding the body) for nullable
fields; allowances could presumably be made if the use cases were
strong.

> Ok - with all of that assumed, I am seriously struggling to 
> think of a real-world use case for generics beyond the 
> compelling operator overloading example.

Generic functions can be useful for adding type-dispatched functionality
after the fact without creating facades/wrappers.  The visitor pattern
is one example that's repeated in the literature.  I circulated a JSON
approach recently based on generic functions, along these lines:

generic function toJSON(x);

generic function toJSON(x:Object) { 
  for ( let n in obj )
    if (obj.hasOwnProperty(n))
      serialize(n, toJSON(obj[n]))
}

generic function toJSON(x:string) { 
  ... 
}

The key here is that the protocol for JSON conversion is defined outside
the object, not inside the object, which can be a real advantage if
you're hooking up to somebody else's code that you don't want to edit.

If you are happy in a class-based OO world and you control all your
source code, you'll probably have limited use for generic functions,
just like you'll have limited use for structural types.  These features
speak to different use cases having to do with evolutionary programming.
(I'm working on a tutorial, which will probably not be finished this
week).

> Assuming that I wanted to continue to try to do method 
> overloading, it sounds like the de-facto solution is to just 
> use the rest arguments to figure out what I want. This is not 
> an acceptable solution. I lose virtually all of the benefits 
> that I had of doing type annotations in the first place if I 
> can't actually use them on "overloaded" functions.

What you mean is, you want parameter lists of different lengths on the
generic methods.

> For example, I've been pouring through my JavaScript library 
> (jQuery) looking for ways in which ES4 could be of benefit. I 
> immediately looked to using (what I thought was) method 
> overloading to ease some of the severe complexity of the 
> library. We do overloading on virtually every single method: 
> Thus, if there was no form of method overloading included in 
> ES4, then jQuery would receive significantly less, tangible, 
> benefit from these updates.
> 
> To give a couple, crude, examples:
> 
> function attr(name : string) : string {
>   // get attribute value
> }
> 
> function attr(name : string, value : (string,int)) : jQuery {
>   // set an attribute value, return a jQuery object }
> 
> function removeEvent() : jQuery {
>   // Remove all events
>   for each ( var type in types )
>     removeEvent( type );
> }
> 
> function removeEvent(type : string) : jQuery {
>   // Remove all events of a specific type
>   for each ( var fn in events[type] )
>     removeEvent( type, fn );
> }
> 
> function removeEvent(type : string, fn: Callable) : jQuery {
>   // Remove the event handler bound to a type }
> 
> Additionally, I've been working on building a DOM 
> implementation to sit on top of the ES4 RI, but have hit some 
> walls, especially with constructors. Thankfully, 
> private/protected/etc. constructors will be implemented at 
> some point (I'm looking forward to it) but I was kind of 
> expecting the ability to do multiple constructors - and even 
> the ability to mix private/protected/public constructors, for example:
> 
> class Foo {
>   private function Foo(){
>     // Do initialization stuff
>   }
>   function Foo(name : string) {
>     this();
>     this.name = name;
>   }
> }
> 
> I'm simply most concerned about getting a useful version of 
> method overloading and constructor overloading. I'd love to 
> find out that I could use generics to achieve this, but I 
> just don't have a way of determining that right now.

As I wrote above, an early version of the generic function proposal
supported multiple parameter list lengths and allowed generic functions
to be instance methods.  The proposal was complicated; I don't know if
it was sound, and it probably would not have been accepted in that form.

If you don't care about extending a generic function outside the class
it's defined in (excluding also extensions in the subclass) because you
just want to implement overloaded functions then there are no problems
with having generic functions be instance methods.  There are also no
problems with having generic constructors or meta:: functions.

What you suggest above with private/public constructors isn't
expressible with generic functions, and I don't expect it ever will be.
(Your example is not a strong use case given that you call the private
constructor from the public one; the private constructor could just be a
private method.)

Parameter lists of various lengths... I understand the use cases, and if
there are no optional or rest arguments involved it's not actually all
that hard.  It's when you try to generalize that it becomes difficult.

IMO we have a couple of options:
  * remove generic functions from ES4 because they are too limited.
Operator overloading goes away, too.
  * accept them as they are, recognizing that they are future-proof and
that they can be extended in later editions of the language (as we've
done for type parameterization)
  * try to extend them with instance methods, constructor methods,
variable-length parameter lists without going over the complexity budget

--lars