Operator overloading revisited

Mark S. Miller erights at google.com
Sun Jun 28 15:54:20 PDT 2009

On Sun, Jun 28, 2009 at 2:51 PM, Christian Plesner Hansen <
christian.plesner.hansen at gmail.com> wrote:

> 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.

For objects that already have a '+' behavior, yes. The issue isn't only
built-in and operators. If library L1 defines constructor C1 that makes
objects that respond in a certain way when their foo method is called, then
it is monkey patching if library L2 loaded later modifies C1.prototype to
alter the foo behavior of these instances. L1 may or may not be designed in
the expectation that other libraries will monkey patch it. If it wishes to
prevent such monkey patching, it can do so by freezing, say, C1 and

However, if L2 introduces creates distinct objects that respond to foo in a
different way, that is not a monkey patch of L1. Hence the introduction of a
distinct Operable in the original proposal.

> 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.

Interesting. This is worth exploring.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20090628/3d0e5a5e/attachment.html>

More information about the es-discuss mailing list