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:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 > >> > [email protected] > >> > https://mail.mozilla.org/listinfo/es4-discuss > >> > > >> _______________________________________________ > >> Es4-discuss mailing list > >> [email protected] > >> https://mail.mozilla.org/listinfo/es4-discuss > >> > > > > > > > > _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
