Multiple Inheritance (Real Studio network user group Mailinglist archive)

Back to the thread list
Previous thread: Shell exceptions
Next thread: slow Tip window on powerbooks


Multiple Inheritance   -   Brad Weber
  Re: Multiple Inheritance   -   Joseph J. Strout
   Re: Multiple Inheritance   -   Greg Ewing
    Re: Multiple Inheritance   -   Norman Palardy
  Re: Multiple Inheritance   -   Brad Weber
   Re: Multiple Inheritance   -   Greg Ewing
  Re: Multiple Inheritance   -   Brad Weber

Multiple Inheritance
Date: 13.12.02 17:34 (Fri, 13 Dec 2002 09:34:14 -0700)
From: Brad Weber
If I understand correctly, class interfaces are the road to
implementing multiple inheritance in RB. I understand that class
interfaces only define an interface and do not store any method code
or properties. So, where should those things exist?

I will declare each class interface method in each class which
implements it. However, if each of those classes is going to
implement the functionality in the same way, I don't want to
duplicate the code in each class. Should I create a module for the
method code? Or should I create another class which can be
instanciated by and referenced by the interface-implementing class to
handle the actual work of the class interface?

Brad Weber

FlatTop Technology, Inc.
---
Custom Software Solutions

http://www.FlatTopTechnology.com

Ph. 303.635.8055
Fax 303.635.1845

---
A searchable archive of this list is available at:
<http://dbserver.realsoftware.com/KBDB/search.php>

Unsubscribe:
<mailto:<email address removed>>

Subscribe to the digest:
<mailto:<email address removed>>

Re: Multiple Inheritance
Date: 13.12.02 19:27 (Fri, 13 Dec 2002 10:27:04 -0800)
From: Joseph J. Strout
At 9:34 AM -0700 12/13/02, Brad Weber wrote:

>If I understand correctly, class interfaces are the road to
>implementing multiple inheritance in RB.

Well, more precisely, RB doesn't *have* multiple inheritance, but it
does have class interfaces. (Just like Java in this regard.)

> I understand that class interfaces only define an interface and do
>not store any method code or properties. So, where should those
>things exist?

They shouldn't. As you say, a class interface only defines an
interface. If you need code and properties, then you don't have
occasion to use a class interface -- use something else.

>I will declare each class interface method in each class which
>implements it. However, if each of those classes is going to
>implement the functionality in the same way, I don't want to
>duplicate the code in each class. Should I create a module for the
>method code? Or should I create another class which can be
>instanciated by and referenced by the interface-implementing class
>to handle the actual work of the class interface?

The latter (i.e., a delegate class). This is in fact a far more
powerful paradigm than always relying on inheritance. Inheritance is
only one way to provide shared but customized code; delegates are
another. Most beginning OOP developers rely far too much on
inheritance.

Cheers,
- Joe

Re: Multiple Inheritance
Date: 15.12.02 22:47 (Mon, 16 Dec 2002 10:47:48 +1300 (NZDT))
From: Greg Ewing
"Joseph J. Strout" <<email address removed>>:

> [Delegation] is in fact a far more powerful paradigm than always
> relying on inheritance. Inheritance is only one way to provide
> shared but customized code; delegates are another. Most beginning
> OOP developers rely far too much on inheritance.

Used properly, multiple inheritance can be a very powerful technique
too. Sometimes multiple inheritance of implementation is just exactly
what you want, and when it is, having to work around the lack of it by
delegation is tedious.

I suspect that the absence of multiple inheritance in many languages
is mostly because it's harder to implement, and the philosophical
reasons for avoiding it are put forward after the fact.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. |
<email address removed> +--------------------------------------+

---
A searchable archive of this list is available at:
<http://dbserver.realsoftware.com/KBDB/search.php>

Unsubscribe:
<mailto:<email address removed>>

Subscribe to the digest:
<mailto:<email address removed>>

Re: Multiple Inheritance
Date: 16.12.02 00:56 (Sun, 15 Dec 2002 16:56:26 -0700)
From: Norman Palardy
Or that they've used a different mechanism that provides similar
benefits without the complexity of implementing multiple inheritance

Interfaces in Java, and in RB, seem to be the alternative

On Sunday, December 15, 2002, at 02:47 PM, Greg Ewing wrote:

> "Joseph J. Strout" <<email address removed>>:
>
>> [Delegation] is in fact a far more powerful paradigm than always
>> relying on inheritance. Inheritance is only one way to provide
>> shared but customized code; delegates are another. Most beginning
>> OOP developers rely far too much on inheritance.
>
> Used properly, multiple inheritance can be a very powerful technique
> too. Sometimes multiple inheritance of implementation is just exactly
> what you want, and when it is, having to work around the lack of it by
> delegation is tedious.
>
> I suspect that the absence of multiple inheritance in many languages
> is mostly because it's harder to implement, and the philosophical
> reasons for avoiding it are put forward after the fact.
>

---
A searchable archive of this list is available at:
<http://dbserver.realsoftware.com/KBDB/search.php>

Unsubscribe:
<mailto:<email address removed>>

Subscribe to the digest:
<mailto:<email address removed>>

Re: Multiple Inheritance
Date: 13.12.02 22:14 (Fri, 13 Dec 2002 14:14:55 -0700)
From: Brad Weber
> >I will declare each class interface method in each class which
>>implements it. However, if each of those classes is going to
>>implement the functionality in the same way, I don't want to
>>duplicate the code in each class. Should I create a module for the
>>method code? Or should I create another class which can be
>>instanciated by and referenced by the interface-implementing class
>>to handle the actual work of the class interface?
>
>The latter (i.e., a delegate class). This is in fact a far more
>powerful paradigm than always relying on inheritance. Inheritance is
>only one way to provide shared but customized code; delegates are
>another. Most beginning OOP developers rely far too much on
>inheritance.

I'm implementing a listener/notifier system (the Observer pattern
from 'Design Patterns'). I've created a class interface for
"listener" and another for "notifier". I've also created a full-blown
class for "notifier" which contains the code and properties which do
the real work. I did not create a class for "listener" because the
interface only defines one method and its implementation could vary
widely from implementing class to implementing class.

In order for an object to be a "notifier", its class must support the
notifier class interface and maintain one private property which
stores a reference to a notifier object. When a notifier method is
called in the implementing object, it just forwards the request to
its notifier property to handle the work.

Does that sound like a reasonable solution? After reading your reply,
I'm also researching the Mediator pattern. Is that the same as the
"delegate class" you mentioned?

Brad Weber

FlatTop Technology, Inc.
---
Custom Software Solutions

http://www.FlatTopTechnology.com

Ph. 303.635.8055
Fax 303.635.1845

---
A searchable archive of this list is available at:
<http://dbserver.realsoftware.com/KBDB/search.php>

Unsubscribe:
<mailto:<email address removed>>

Subscribe to the digest:
<mailto:<email address removed>>

Re: Multiple Inheritance
Date: 15.12.02 23:22 (Mon, 16 Dec 2002 11:22:41 +1300 (NZDT))
From: Greg Ewing
Brad Weber <<email address removed>>:

> In order for an object to be a "notifier", its class must support the
> notifier class interface and maintain one private property which
> stores a reference to a notifier object. When a notifier method is
> called in the implementing object, it just forwards the request to
> its notifier property to handle the work.

It sounds like you're not gaining anything by having the interface for
notifier objects at all. If every notifying object is required to
provide an implementation of notify() which goes

sub notify(whatever as something)
myNotifier.notify(whatever)
end sub

then, as long as any calls to this method are only made from the
object itself (or a subclass) there's no need for this method to be
declared in any interface.

Generally, the only reason you need an interface is to satisfy the
static type checking when methods need to be called from *another*
object. You never need to provide an interface to *yourself*.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. |
<email address removed> +--------------------------------------+

---
A searchable archive of this list is available at:
<http://dbserver.realsoftware.com/KBDB/search.php>

Unsubscribe:
<mailto:<email address removed>>

Subscribe to the digest:
<mailto:<email address removed>>

Re: Multiple Inheritance
Date: 16.12.02 05:14 (Sun, 15 Dec 2002 21:14:01 -0700)
From: Brad Weber
>Brad Weber <<email address removed>>:
>
>> In order for an object to be a "notifier", its class must support the
>> notifier class interface and maintain one private property which
>> stores a reference to a notifier object. When a notifier method is
>> called in the implementing object, it just forwards the request to
> > its notifier property to handle the work.

"Greg Ewing" <<email address removed>>

>It sounds like you're not gaining anything by having the interface for
>notifier objects at all. If every notifying object is required to
>provide an implementation of notify() which goes
>
> sub notify(whatever as something)
> myNotifier.notify(whatever)
> end sub
>
>then, as long as any calls to this method are only made from the
>object itself (or a subclass) there's no need for this method to be
>declared in any interface.
>
>Generally, the only reason you need an interface is to satisfy the
>static type checking when methods need to be called from *another*
>object. You never need to provide an interface to *yourself*.

You make a good point about notify(). It should only be called from
within an object of the same class when an event occurs in that
object about which other objects should be notified. However, a
Notifier also needs to support AddListener() and RemoveListener().
Those will be called from other objects.

Brad Weber

FlatTop Technology, Inc.
---
Custom Software Solutions

http://www.FlatTopTechnology.com

Ph. 303.635.8055
Fax 303.635.1845

---
A searchable archive of this list is available at:
<http://dbserver.realsoftware.com/KBDB/search.php>

Unsubscribe:
<mailto:<email address removed>>

Subscribe to the digest:
<mailto:<email address removed>>