> 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. _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
