Understanding Generic Functions

[Lars Hansen]

> -----Original Message-----
> From: P T Withington [mailto:ptwithy at gmail.com] On Behalf Of 
> P T Withington
> Sent: 15. november 2007 14:02
> To: Lars Hansen
> Cc: John Resig; es4-discuss
> Subject: Re: Understanding Generic Functions
> 
> On 2007-11-15, at 02:52 EST, Lars Hansen wrote:
> 
> [...]
> 
> > Generic functions can be useful for adding type-dispatched 
> > functionality after the fact without creating facades/wrappers.
> 
> My view is that generic functions recognize that any function 
> with more than one class parameter can't logically belong to 
> any particular class.  They allow behaviors between classes 
> to be described logically, rather than being artificially 
> attached to one of the classes of their parameters.

Right, the binary method problem (even for larger values of "binary").

> Hey, can I say something like:
> 
> generic function get a (this: Foo) ?

Not at the moment, but this came up briefly the other day, I forget if
it was on this list or elsewhere, that maybe there is a global generic
function meta::get (just like there is a global intrinsic::+), and if
property lookup fails in an object the dispatch would go through that
function.  No decision on that (not even a ticket).

This discussion highlights the fact that generic functions sometimes
feel a little bolted on, because there are already class protocols that
do part of what generic functions do.  We're really not trying to do a
MOP for ES4, it's just that once we have generic function it's so easy
to be tempted.  "Just a little tweak here."

> [...]
> 
> > 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 insta
> 
> Is my mail client broken, or did you hit send too soon?

The former, probably.  The last bullet (and the end of the message) was:

* try to extend them with instance methods, constructor methods,
variable-length parameter lists without going over the complexity budget

(I'm adding this pointless sentence here in case the bug in your mail
reader has to do with signature removal being thrown off by the bullet
starting the line above, or something silly like that.)

--lars