Class method addition and replacement (was Re: AOP Compatibility)
brendan at mozilla.org
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
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
> 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?
More information about the Es4-discuss