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

Peter Hall peter.hall at memorphic.com
Thu Apr 3 17:20:19 PDT 2008


If you want mutability, you can define methods as vars in the first place.

class Foo {

  // can be modified on a per-instance basis
  public var f : function (a:T):S = function (a:T):S {
      return null;
  }

}


but that is an explicit intent to permit that behaviour by the class author.

Peter



On Fri, Apr 4, 2008 at 1:02 AM, Kris Zyp <kris at sitepen.com> wrote:
>
> > 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