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

Brendan Eich brendan at
Thu Apr 3 13:11:19 PDT 2008

On Apr 3, 2008, at 8:23 AM, Kris Zyp wrote:

>>> the moment, but I assume you can't do replace a method on a user   
>>> class
>>> with
>>> another ad-hoc function.
>> Absolutely not with fixtures,
> I was thinking about this, is there any reason why you can't replace a
> class's method with another method or install a method on an  
> instance object
> that overrides the class's method, assuming that the method signature
> remains the same, the body has correct typing use of |this|, and  
> the class
> is non-final? This seems to have the same integrity as method  
> overriding in
> subclasses. Being able to do this (and possibly dynamically adding  
> methods
> to classes) would bring the level of dynamicism that Mark had  
> suggested with
> his ES4 sugar proposal (being able to create classes on the fly)

Mark's sketch did not allow method replacement, however.

AOP is not the root password to mutation barriers added to enforce  
integrity properties. It is not even formally sound, last I looked.  
And its main use-case is logging or other such post-hoc, cross- 
cutting instrumentation. If the universe of objects already contains  
some (like certain built-in objects including DOM nodes in most  
browsers) whose methods cannot be replaced, which must therefore be  
wrapped for AOP-style hacking, then why wouldn't we want classes to  
behave as proposed in ES4?

Wrappers will be required; they already are for security in browsers  
I've studied (or they are coming soon, at any rate). Any code not  
insisting on a nominal type relation, i.e., using * (implicitly as in  
untyped code today, or explicitly), or a like test, or a structural  
subtype test, could let wrappers through. Just as DOM wrappers can  
satisfy hand-coded "shape tests" in today's untyped libraries that  
use AOP.


More information about the Es4-discuss mailing list