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

Lars Hansen lhansen at adobe.com
Thu Apr 3 18:12:10 PDT 2008


Most of the time I would not agree that "changing a method
is an explicit indication that a developer doesn't want 
the class to be invariant".  Most of the time it's just an
indication that I'm (a) hacking to make something (appear to)
work or (b) tired and making a mistake.  And this goes
doubly for team programming and for programs that have a
long maintenance life.

Classes provide the integrity that is necessary for large 
systems written by many people over significant periods of
time to work; such systems reward commitments to invariants
even if those invariants later can become a straightjacket
(and require reengineering).  In such a system the variation
points are (and need to be) explicit.  

--lars

> -----Original Message-----
> From: Kris Zyp [mailto:kris at sitepen.com] 
> Sent: 3. april 2008 18:02
> To: Lars Hansen; Peter Hall
> Cc: es4-discuss Discuss
> Subject: Re: Class method addition and replacement (was Re: 
> AOP Compatibility)
> 
> > 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.
> 
> But if I want the class to behave exactly the same as when I 
> created, why would I change the method? Isn't changing a 
> method an explicit indication that a developer doesn't want 
> the class to be invariant?
> I believe this is more a philosophical/preferential question. 
> Do you value class integrity/immutably more or 
> dynamicism/mutably? Obviously my preference is towards the 
> latter camp, but perhaps I am in the minority, and the 
> concerns over efficiency are certainly important as well.
> Thanks,
> Kris
> 
> 
> >
> > (There are efficiency concerns too, but I think the violation of 
> > integrity is the important part.)
> >
> > --lars
> >
> >> -----Original Message-----
> >> From: es4-discuss-bounces at mozilla.org 
> >> [mailto:es4-discuss-bounces at mozilla.org] 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 sitepen.com> 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 mozilla.org
> >> >  https://mail.mozilla.org/listinfo/es4-discuss
> >> >
> >> _______________________________________________
> >> Es4-discuss mailing list
> >> Es4-discuss at mozilla.org
> >> https://mail.mozilla.org/listinfo/es4-discuss
> >>
> >
> >
> > 
> 
> 



More information about the Es4-discuss mailing list