« Return to Thread: Operator overloading revisited

Re: Operator overloading revisited

by Mark S. Miller-2 :: Rate this Message:

On Sun, Jun 28, 2009 at 2:51 PM, Christian Plesner Hansen <christian.plesner.hansen@...> 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

yes

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

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.

--
Cheers,
--MarkM

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

« Return to Thread: Operator overloading revisited