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

Kris Zyp kris at sitepen.com
Thu Apr 3 17:02: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.

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