Operator overloading revisited
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
"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
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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss