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.
(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
