On Sun, Jun 28, 2009 at 2:51 PM, Christian Plesner Hansen < [email protected]> 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
