On Thu, 3 Oct 2002, Michael Lazzaro wrote: > > 1) Delegation through inheritance: > (a.k.a. "mixin" classes, "hard delegation", "concrete interfaces", > etc., etc.) > > Example: I want to say that a class DataManager has the capabilities > of the interfaces DataStrategy and CacheStrategy, but is not strictly a > "subclass" of either. In other languages, this might appear like: > > class DataManager implements DataStrategy, CacheStrategy { ... } > - or - > class DataManager mixin DataStrategy, CacheStrategy { ... }
Aside from runtime mixin', in what way does inheritance _not_ do what you want? > 2) Delegation through attribute: > (a.k.a.... "soft delegation", "instance-based delegation", etc., etc.) > > The ability to specify that, if an instance of an object DataSnippet > is affiliated with a specific, runtime instance of a DataManager, e.g. > > class DataSnippet { > attr $data_manager is DataManager; > } > > ... then [some, all] public methods of $self.data_manager can > automatically be delegated by the DataSnippet to that specific > instance, eliminating the need for code that makes you want > to kill yourself: > > method foo (...) { $self.data_manager.foo( ... ) } > method bar (...) { $self.data_manager.bar( ... ) } > # ... repeat until carpel tunnel syndrome sets in ... Reaction #1: Only on a perl list would it occur to people to complain about that. :) Reaction #2: Inheritance would automatically delegate all those methods, so again, in what way does inheritance _not_ solve the problem? Finally, a question about interfaces: In what way is an interface different from a pure abstract class (i.e. containing only method declarations, but no code)? ~ John Williams DISCLAIMER: This post assumes perl6 will have multiple inheritance.