On Fri, Jan 16, 2009 at 5:34 PM, Brendan Eich <bren...@mozilla.com> wrote:
> Have you looked at multimethods in Cecil? > > http://www.cs.washington.edu/research/projects/cecil/pubs/cecil-oo-mm.html > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.8502 On your recommendation, I have. I really wanted to like it. I really tried to like it. In the end I was repelled in horror at its complexity. > Good discussion, let's keep it going. > Indeed. After I made a simple proposal < https://mail.mozilla.org/pipermail/es-discuss/2009-January/008535.html>, Michael Daumling pointed out that Adobe had made a similar proposal that had been rejected: On Fri, Jan 9, 2009 at 7:56 AM, Michael Daumling <mdaeu...@adobe.com> wrote: > > The discussion about operator overloading quickly went away from the > JavaScript'ish approach that ExtendScript and your proposal used towards > generic functions. At some time, the discussion stranded in areas too exotic > for me. There is a rationale here: > http://wiki.ecmascript.org/doku.php?id=discussion:operators > The objections listed there are I think this feature is too weak to be included. Here are some reasons why I > think that: > > - Uncontrollable subtleties in dispatch: Adding eg a == operator to one > class and then comparing an instance x of that class to a value y of > another type means that the result can easily differ depending on whether > the programmer writes x == y or y == x. (If y has an operator == too > then its operator will be preferred in the latter case.) The most the > author > of the == operator can do about this is to add types to the operator's > signature so that strict mode catches the bug or the program fails > predictably at run-time. > > I'd argue that this is a feature, not a bug. Whether an operator is commutative depends on the meaning of that operator on that data type. "x * y" should mean the same as "y * x" if they are scalar numbers but not if they are matrices. > > - > - No inheritance: in almost all cases we would wish that if instances > of A and B are comparable with a certain semantics then instances of their > respective subclasses C and D are too. > > That objection doesn't apply to my proposal. (I'm not sure it does to Adobe's either.) > > - > - No compositionality: As the operators are tied to classes, a program > that wishes to use two separately authored classes A and B cannot define > their relations in terms of operators, the classes must be altered because > they do not know about each other. > > Again, I'd argue that this is a feature, not a bug. Likewise, if I see the expression "x.foo(y)" and the meaning of the foo operation does not treat its operands opaquely, if neither x nor y know about each other's interface, then I'd expect the operation to fail. If some party outside of x and y could define a generic foo that could make this operation succeed anyway, I'd consider that a bug. > > - > > Including operators as currently proposed would probably give us a headache > if we wish to introduce a more powerful feature (probably based on some sort > of ad-hoc overloading) in the future. > Functional folks often refer to oo polymorphism (or "late binding") as "ad-hoc polymorphism", to distinguish it from their parametric polymorphism. If this is what is meant, then my proposal and Adobe's both provide ad-hoc polymorphism. If, as I suspect, something else is meant, I await hearing what it might be. -- Cheers, --MarkM
_______________________________________________ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
