Operator overloading revisited
Christian Plesner Hansen
christian.plesner.hansen at gmail.com
Wed Jul 1 08:14:39 PDT 2009
> This cuts both ways. A multimethod reifies that "global" (lexically scoped,
> rather) cache.
Sure, I'm not saying it's unique to my proposal. I mention it because
it's an important aspect to keep in mind when considering the cost of
implementing it in practice.
> Sorry, I kept typing "asymmetric" when I meant "symmetric". Tired
> here (new baby at home :-)).
Congratulations! And congratulations on firefox 3.5 too by the way!
> Below you allow for internal properties, so presumably ("this+" in a) would
> *not* evaluate to true for (a + b) in your examples. So why require"this+"
I'm all for internal properties rather than "this+" and "+this".
>> Methods live on objects and their prototypes. Operators should too.
> Saying that methods should "live" (be bound) somewhere when they do not use
> |this| to denote the receiver in which they are bound (directly or on the
> prototype chain) seems like even weaker dogma. Mark's double-dispatch is
> consistent with OOP. Your proposal seems to require reciprocal external
> property mutations on prototypes but only so the dispatch algorithm can do
> its simplified CPL thing. Why?
All things being equal I'd probably rather have operator functions
outside objects or prototypes. But things are not equal.
Relying on a connection between constructor functions and instances is
fragile, as I mentioned in a previous message to Mark about
instanceof. You can make changes to a constructor function that is
not reflected in existing instances. You can make changes both to
instances and constructors that disconnect the two completely.
Constructor functions are implementation types (as opposed to
interface or behavior types) which is inherently problematic. I
wouldn't make this weak connection the cornerstone of operator
The connection between prototypes and instances is a much more direct
one. If you change a prototype that change is reflected in the
instances (modulo shadowing). If I want my type B to have all the
same behavior as A I can mix all the methods of A into B's prototype
and I will in effect have made B a subtype of A. If operators reside
in A's prototype, in whatever form, I can do the same for operators.
Whether or not A's '+' operator uses 'this', it's still a part of A's
behavior and the most consistent place to put it is where A's other
behavior is, its prototype.
>> Using a special internal property rather than plain old properties is
>> fine by me but they should be directly associated with the objects
> Directly? You wrote "and their prototypes" above, and your
> Function.defineOperator examples were passed constructors (from which to
> mutate prototypes), not direct instances:
Right, I could have been more explicit about that. I do mean
including prototypes, they fall under "objects involved".
More information about the es-discuss