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

2008-04-05 Thread Nathan de Vries
On 04/04/2008, at 1:35 PM, Brendan Eich wrote:
 EIBTI!

Perhaps not the best reference given the topic, given that Python  
makes class overriding and resurrection of overridden classes  
possible with their __builtin__ module.

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. Monkey patching is prevalent on the web, and I  
believe that the practice should be supported, not feared. 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 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?

--
Nathan de Vries
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss


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

2008-04-05 Thread Brendan Eich
On Apr 5, 2008, at 12:42 AM, Nathan de Vries wrote:

 On 04/04/2008, at 1:35 PM, Brendan Eich wrote:
 EIBTI!

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

 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.

/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss