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

Lars Hansen lhansen at
Thu Apr 3 12:45:20 PDT 2008

Just to echo Peter here, changing a method violates integrity in
the worst way.  If I say "new Cls" I *know* that the object I get
is of type Cls, and if I know the implementation of that class I
know what a call to a method of the type will do.  There is no
way subclassing can get in the way of that knowledge, but allowing
methods to be arbitrarily assigned to (even with constraints on
type compatibility) completely destroys that invariant.  But that
invariant is one of the main benefits of having classes in the
first place.

(There are efficiency concerns too, but I think the violation of
integrity is the important part.)


> -----Original Message-----
> From: es4-discuss-bounces at 
> [mailto:es4-discuss-bounces at] On Behalf Of Peter Hall
> Sent: 3. april 2008 09:58
> To: Kris Zyp
> Cc: es4-discuss Discuss
> Subject: Re: Class method addition and replacement (was Re: 
> AOP Compatibility)
> Replacing a method effectively changes the type, even if the 
> signature is the same. If some code creates an instance of a 
> class using "new"
> it should be able to rely on it being that type, and make 
> assumptions about how that object will behave. (This is not a 
> matter of breaking polymorphism because the same code created 
> the instance such that there is no possibility of a sub-type 
> instance being present).
> Allowing methods to be replaced means that other parts of a 
> program could alter the behaviour of an object in a way that 
> could contradict those assumptions.
> Additionally, allowing methods to be replaced could reduce 
> the effectiveness of early binding optimisations. (Jeff Dyer 
> can correct me if I'm inaccurate here..) In AS3, class 
> methods are referenced via the class's traits table. They may 
> be accessed by name, but calls are bound to addresses where 
> possible, at compile time via the traits.
> Allowing methods to be overridden would mean a choice of 
> copying the traits for each instance, which would increase 
> memory usage dramatically; or else checking for overrides at 
> runtime for every method call, which would hurt performance.
> Peter
> On Thu, Apr 3, 2008 at 4:23 PM, Kris Zyp <kris at> 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), but  without 
> > destroying the fundamental ES4 typing/fixture system. This 
> could be  
> > used to solve AOP as well, and bring a distinctly higher level of 
> > dynamicism  which could be leveraged to progressively 
> build, serialize (with proper  introspection), and 
> deserialize classes.
> >
> >  Essentially, are there mutations to classes and object 
> instances that 
> > do not  effect integrity and do not violate explicit 
> contracts against 
> > mutation  (final annotation=no method mutations) that we 
> could allow?
> >
> >  Thanks,
> >  Kris
> >
> >  _______________________________________________
> >  Es4-discuss mailing list
> >  Es4-discuss at
> >
> >
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at

More information about the Es4-discuss mailing list