« Return to Thread: Operator overloading revisited

Re: Operator overloading revisited

by Brendan Eich-3 :: Rate this Message:

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

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

« Return to Thread: Operator overloading revisited