Operator overloading revisited
Christian Plesner Hansen
christian.plesner.hansen at gmail.com
Sun Jun 28 14:51:55 PDT 2009
> I note that your symmetric suggestion avoids the problem of most other
> symmetric overloading systems, like Cecil, of diffusion of responsibility.
> Since your's only proceeds under mutual agreement, both operands are
> responsible for the result. Unfortunately, this means that new libraries
> like Point, in order to allow "pt + number" or "number + pt", must in
> practice monkey patch Number.prototype to know about these new overloads.
> Should Number.prototype in that frame (global object context) already be
> frozen to prevent such monkey patching, then this Point extension can no
> longer be loaded into that frame.
Can you give me some context on freezing built-ins? What's the
purpose? If it is to prevent the behavior of numbers to change under
people's feet then you might argue that preventing libraries from
changing the behavior of '+' is a good thing.
Note that adding an operator doesn't actually have to change
Number.prototype -- what it changes is the list of operator functions.
You could allow that even if Number.prototype is frozen. It would
still be "monkey patching" but if you use something less general than
a list, say an OperatorCollection that you could only add to, maybe it
would be okay. Again, I don't know the exact purpose of freezing
types this way so it's hard for me to tell if that solves the problem.
More information about the es-discuss