Class method addition and replacement (was Re: AOP Compatibility)

Brendan Eich brendan at
Sat Apr 5 07:38:01 PDT 2008

On Apr 5, 2008, at 12:42 AM, Nathan de Vries wrote:

> On 04/04/2008, at 1:35 PM, Brendan Eich wrote:
> Perhaps not the best reference given the topic, given that Python
> makes class overriding and resurrection of overridden classes
> possible with their __builtin__ module.

Good point. Slogans like EIBTI are too binary to handle the fullness  
of Python, never mind JS. Let's stick to ES3 and ES4 here. Since no  
one is proposing to do away with dynamic typing or mutable objects in  

> I'm actually quite surprised to hear that there are so many on this
> list who are happy to drop EcmaScript's usual dynamicism in favour of
> so called "integrity".

...  "drop" here is false. We're adding missing tools to make  
immutable properties and objects that can't be extended, that's all.

> Monkey patching is prevalent on the web, and I
> believe that the practice should be supported, not feared.

How about both? ;-)

I picked mutable by default in JS1 intentionally, because it allowed  
content authors to monkey-patch or wholesale-mutate the built-in  
objects, to work around bugs or simply suit their own needs. This was  
assuming a same-origin single trust domain.

Two things have happened since 1995 (really, both started happening  
right away in 1996, but few noticed):

1. JS code has scaled up to "programming in the large" domains, where  
even without hostile code or mutual suspicion, producers and  
consumers of library code want greater integrity properties than they  
can enforce with closures for private variabables (which are still  
mutable objects).

2. JS from different trust domains is being mixed, most obviously via  
script injection (for advertising, among other things), to overcome  
same-origin restrictions. Fixing this takes more than integrity in my  
view (confidentiality via secure information flow is something we're  
researching at Mozilla, partnering with others). But integrity is  
foundational, non-optional.

> Sure,
> developers will be able to explicitly mark areas in their code which
> they deem appropriate for another developer to change, but that
> strikes me as a bit of a fantasy land.

The fantasy here would be that JS has been kept down on the same- 
origin and small-scale storybook farm where it was born. It's in the  
big city now. ;-)

> The majority of code which requires patching by external developers
> was never written to be patched, but people do it anyway. This is
> good, don't you agree?

See above.


More information about the Es4-discuss mailing list