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

Peter Hall peter.hall at
Thu Apr 3 08:58:05 PDT 2008

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.


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

More information about the Es4-discuss mailing list