> -----Original Message----- > From: Jonathan Lang [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 29, 2004 1:29 AM > To: Joseph Ryan; Dmitry Dorofeev > Cc: Perl6 Language List > Subject: Re: OO inheritance in a hacker style > > > Joseph Ryan wrote: > > > Of course, roles are another great way to prevent confusion with > > multiple inheritance. A good question would be whether something > > like "forget" is useful in addition, or whether everyone should > > just use roles. :) > > For the record, roles are not a form of multiple inheritence. They're > similar in that both are techniques for code re-use; but there are crucial > differences - for instance, classes call methods; roles merely provide > methods for classes to call. > > How about this: allow for two approaches for calling a given method: > implicit (state the object and the method, and leave it up to the class > dispatcher to figure out where the method is to be found - in the class, > one of its roles, or one of its parents) or explicit (state the object, > the method, and the class or role where it will be found). Allow > exclusion of inherited and role methods, but define exclusion strictly in > terms of implicit calls: you're telling the class dispatcher to ignore > that role or parent when searching for candidate methods to call. > > Explicit calls would suffer from "brittleness" - that is, if you rename a > role or a class, you'd need to hunt down every instance where one of its > methods is explicitly called and rename it there as well. Implicit calls, > OTOH, would risk incompleteness - exclude an inherited or role method from > a class without providing a valid substitute, and other code may end up > assuming that the class has capabilities that it doesn't.
I think that both of these capabilities are already present in P5, and have been agreed upon for P6: $obj->foo(); # dispatches, and Class::Subclass $obj; # explicitly invokes. > The danger isn't really in the ability to suppress a method from a given > role or parent; the danger comes from the ability to suppress a method > from _every_ role or parent. A safe alternative to this would be to > define a class method which then turns around and explicitly calls the > inherited or role method that you really wanted; the drawback here is the > poor Huffman encoding involved: writing a method is considerably more > bulky than saying "exclude ..." or "rename ...". You can resolve this > dilemma in two ways (not mutually exclusive): forbid the latter options, > or come up with a more succinct way of handling the former option. I don't think this is a disadvantage. Consider that ROLES already require some similar feature: When two roles have methods that conflict, there is a requirement to suppress or rename one or both methods. Consider also that suppression across the board would be a valid Aspect-Oriented operation. For example, adding or replacing a C<debug> method is a fairly common example. But suppressing the same debug method for use in finished products might be advantageous, especially if it resulted in a smaller compiled executable. To me, the "forget" or "discard" or "dispose" or "delete" (gasp) keyword or operation has a valid place, even if it's not a frequently used place. I guess the question is: Could we successfully implement this in 6.1 as a module? =Austin
