> 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
