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.
