Operator overloading revisited

Brendan Eich brendan at mozilla.com
Mon Jun 29 11:21:49 PDT 2009


On Jun 28, 2009, at 1:24 PM, Mark S. Miller wrote:

> I note that your symmetric suggestion avoids the problem of most  
> other symmetric overloading systems, like Cecil, of diffusion of  
> responsibility.

"Diffusion" sounds like a problem, a bad thing, but consider (I've  
quoted this before) the use-case:

The generalization of receiver-based dispatch to multiple dispatch  
provides a number of advantages. For example, multimethods support  
safe covariant overriding in the face of subtype polymorphism,  
providing a natural solution to the binary method problem [Bruce et  
al. 1995; Castagna 1995]. More generally, multimethods are useful  
whenever multiple class hierarchies must cooperate to implement a  
method’s functionality. For example, the code for handling an event in  
an event-based system depends on both which event occurs and which  
component is handling the event.

MultiJava: Design Rationale, Compiler Implementation, and Applications
Curtis Clifton, Todd Millstein, Gary T. Leavens, and Craig Chambers

http://www.cs.washington.edu/research/projects/cecil/pubs/mj-toplas.html

So there are use-cases involving responsible classes A and B (event  
source and sink), no third parties. But there are also the third party  
cases you're thinking of. The last time this came up (https://mail.mozilla.org/pipermail/es-discuss/2009-January/008715.html 
), I wrote:

Over and over, in Mozilla code and especially on the web, we've seen  
"code mashups" where one does not always have the money, or even the  
ability, to monkey-patch class A or class B to understand each other.  
Wrapping can be done to make a class C with operators, at some cost.  
Why this is always a feature and never a bug is not clear, and  
Chambers, et al. have researched a fix to it, viewing it as a bug to  
motivate their research.

I can't find a reply from you on this :-), so let me take this  
opportunity to ask: how does requiring a third party to create a  
wrapper class C discharge undiffused responsibility in any useful way?

A and B still are not involved in the wrapping done by class C through  
which A and B can become (wrapped) operands to an operator defined by  
C. Often the creation of such a wrapper amounts to expending effort to  
write tedious boilerplate that has non-trivial runtime and space  
overhead.

This may be a "religious" point over which we shouldn't argue --  
Waldemar suggested that it was a difference of "points of view" at the  
TC39 meeting. But it seems to me taking one such point of view ought  
not knock down multimethods, at least not without more precision about  
what exactly is the problem with "diffusion of responsibility" that  
they bring.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20090629/25f7efd6/attachment.html>


More information about the es-discuss mailing list