RE: Delegation syntax? (was: Re: Private contracts)
John Williams: > Reaction #2: Inheritance would automatically delegate all those > methods, so again, in what way does inheritance _not_ solve > the problem? What about when you want to be able to dynamically swap the objects to which you're delegating? -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
Re: Delegation syntax? (was: Re: Private contracts)
John Williams wrote: > Reaction #2: Inheritance would automatically delegate all those > methods, so again, in what way does inheritance _not_ solve the problem? Many real life systems are composed from elements, not inherited from elements. A car is not a wheel, but is composed from 4 (or more). As a simple example, a wheel might implement an inflate() method, but it probably wouldn't make much sense for the car to inherit that method. Rather, you would define inflate_tyres() which delegates to the inflate() method on the tyres on each of the the 4 wheels. Further still, the airbag might also have an inflate() method. If you're not careful and don't inherit all your objects in exactly the right order then you might find your tyres inflating instead of your airbag when you hit a truck. False inheritance leads to method madness. > In what way is an interface different from a pure abstract class (i.e. > containing only method declarations, but no code)? Inheritance and interfaces are two different things. The end result would be pretty much the same in this example, but reaching it by different routes. With inheritance, your derived object inherits all the methods that you don't explicity re-define. With interfaces, you are stating that your object will implement all the methods, either directly or by inheriting from, or delegating to other classes. Thus, inheritance, delegation and interfaces are separate, orthogonal concepts. Inheritance : is Delegation : has Interface : can A
Re: Delegation syntax? (was: Re: Private contracts)
On Thu, Oct 03, 2002 at 07:59:33PM -0600, John Williams wrote: > Reaction #2: Inheritance would automatically delegate all those > methods, so again, in what way does inheritance _not_ solve the problem? I don't think p6l is the right place to discuss the merits of delegation, let's just say it's a Good Thing to have in your OO toolbelt. Solves a lot of problems which would otherwise require hairy, ambiguous multiple inheritance situations. If you're curious I can explain more off-list. > 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)? An interface requires subclassers to implement all abstract methods and they must match the method signatures, conditions and invariants of the interface. A pure abstract class doesn't necessarily require subclasses to do anything, at least not in Perl. So an interface is simply a class, maybe abstract, which requires its subclasses to conform to its signature. At least that's how I see it. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One It's Airplane Glue sniffing time!
Re: Delegation syntax? (was: Re: Private contracts)
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.
Re: Delegation syntax? (was: Re: Private contracts)
On Thu, Oct 03, 2002 at 03:54:09PM -0700, Michael Lazzaro wrote: > I have no *good* syntax proposals for this, I don't think I've ever > seen the problem solved with syntax that I really ever liked. Class::Delegation? -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One MERV GRIFFIN!
Delegation syntax? (was: Re: Private contracts)
On Thursday, October 3, 2002, at 03:18 PM, Paul Johnson wrote:
>> (As a lame aside, are we going to have a concept of "private" vs.
>> "protected" vs. "public", or just private/public?
>
> No protected. Even Stroustrup admits it was a mistake in D&E.
Oh, thank God. I was hoping people would say that.
OK, for an entirely different thread...
Is there an accepted preliminary syntax for OO delegation? (I've
looked and can't find anything definitive.) By "delegation", I mean
two different things (you can tell OO programming has firmly arrived by
the fact that, Babel-like, no group of people can ever agree on the
meaning of any given term, making all conversations painful).
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 { ... }
(yes, I know you probably wouldn't do a Manager/Strategy like that.
it's just an example, and my mind is blanking right now...)
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 ...
I have no *good* syntax proposals for this, I don't think I've ever
seen the problem solved with syntax that I really ever liked.
MikeL
