Smalltalk › Cincom › VisualWorks

Multiple Inheritance

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

27 messages Options

andre

Multiple Inheritance

Hi,

while porting from Smalltalk to C++, I found that multiple inheritance is extremely expressive and helps keep the class tree at a reasonable, relatively low depth. Aside from static typing being a pain, the C++ way of assembling classes from "LEGO blocks of behavior" is fantastic.

I would even dare to say this is far superior compared to a strict hierarchy. I often feel I am forced to put a class where it actually doesn't belong, only to avoid writing redundant code. It also leads to deep and bloated trees with multiple implementations of very similar behavior.

The base image could possibly be 1/4 of its current size with multiple inheritance?

Are there Smalltalk frameworks that support it? I mean, not something that is based on redirection of DNU exceptions. I would love a real toolset that comes with its own browser, compiler, etc.

I could imagine that it would be possible, in theory, to "unfold" a multiple inheritance network into a class hierarchy by physically duplicating the sources of the involved superclasses automatically. Kind of Just-In-Time preprocessor.

Any hope?

Andre

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Mariano Martinez Peck

Re: Multiple Inheritance

On Thu, Jun 7, 2012 at 5:06 PM, andre <[hidden email]> wrote:

Hi,

while porting from Smalltalk to C++, I found that multiple inheritance is extremely expressive and helps keep the class tree at a reasonable, relatively low depth. Aside from static typing being a pain, the C++ way of assembling classes from "LEGO blocks of behavior" is fantastic.

I would even dare to say this is far superior compared to a strict hierarchy. I often feel I am forced to put a class where it actually doesn't belong, only to avoid writing redundant code. It also leads to deep and bloated trees with multiple implementations of very similar behavior.

The base image could possibly be 1/4 of its current size with multiple inheritance?

Are there Smalltalk frameworks that support it? I mean, not something that is based on redirection of DNU exceptions. I would love a real toolset that comes with its own browser, compiler, etc.

It is not the same as multiple Inheritance, but in Pharo Smalltalk you have Traits. Problem is that in their current implementations they are usually stateless. So you can only "inherit" methods, not state.

I could imagine that it would be possible, in theory, to "unfold" a multiple inheritance network into a class hierarchy by physically duplicating the sources of the involved superclasses automatically. Kind of Just-In-Time preprocessor.

Any hope?

Andre

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Georg Heeg

Re: Multiple Inheritance

In reply to this post by andre

Andre,

In the very early 1980ies there was an implementation of multiple
inheritance in Smalltalk written by Alan Borning
(http://www.aaai.org/Papers/AAAI/1982/AAAI82-056.pdf). As this part of
VisualWorks has never changed, it should still work in current version with
reasonable adaptations.

There is also a concept called Traits
(http://en.wikipedia.org/wiki/Trait_(computer_programming) ) you will find
current implementations.

Since the early 1980 there have been discussions about multiple inheritance
in Smalltalk. The conclusion have always been: You don't want it. The most
simple version is: It makes it harder to read code. And reading
(understanding) is the predominant activity in Smalltalk programming.

Typically the desire for multiple inheritance have been a sign of
sub-optimal design and lack of understanding of the domain. The general
solution has been: refactoring and delegation.

Georg

Georg Heeg eK, Dortmund und Köthen, HR Dortmund A 12812
Wallstraße 22, 06366 Köthen
Tel. +49-3496-214328, Fax +49-3496-214712

-----Ursprüngliche Nachricht-----
Von: [hidden email] [mailto:[hidden email]] Im Auftrag
von andre
Gesendet: Donnerstag, 7. Juni 2012 17:06
An: VWNC list
Betreff: [vwnc] Multiple Inheritance

Hi,

while porting from Smalltalk to C++, I found that multiple inheritance is
extremely expressive and helps keep the class tree at a reasonable,
relatively low depth. Aside from static typing being a pain, the C++ way of
assembling classes from "LEGO blocks of behavior" is fantastic.

I would even dare to say this is far superior compared to a strict
hierarchy. I often feel I am forced to put a class where it actually doesn't
belong, only to avoid writing redundant code. It also leads to deep and
bloated trees with multiple implementations of very similar behavior.

The base image could possibly be 1/4 of its current size with multiple
inheritance?

Are there Smalltalk frameworks that support it? I mean, not something that
is based on redirection of DNU exceptions. I would love a real toolset that
comes with its own browser, compiler, etc.

I could imagine that it would be possible, in theory, to "unfold" a multiple
inheritance network into a class hierarchy by physically duplicating the
sources of the involved superclasses automatically. Kind of Just-In-Time
preprocessor.

Any hope?

Andre

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

andre

Re: Multiple Inheritance

Thanks for the pointers, Georg. Interesting read.

I see the points, but am inclined to disagree with such a general verdict against MI. There are legitimate uses for it, although it can certainly be abused to create a mess.

Code readability is, and Smalltalkers know that best, a question of the right tools. Plain source "files" are almost always hard to read, no matter which language.

One interesting thing I recently observed concerning the way my thoughts tend to go is, that the typical thought pattern when creating a new class in Smalltak is "of what existing class *is* this object a derivate or specialization?" It is an ontological model. In contrast, the typical thought in C++ is "what is this object supposed to be able to *do*?", which is a behavioral model.

Either model has its advantages and disadvantages. If for example, I have an object that is supposed to be able to

- Run a background thread
- Receive and process jobs from a queue
- Broadcast events to dependent objects
- Provide a server on a network that clients can connect to
- Receive and react to OS events
- Implement application specific behavior that builds on all the above

then using MI, all but the last point could be simply assembled from existing classes. In Smalltalk, I would need to add a lot of protocols and copy/paste/rewrite code from elsewhere.

Delegation is verbose and laborious and hard to maintain. Also if the individual delegates of an object need to share a great deal of common state, things are getting even more laborious.

Andre

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

jarober

Re: Multiple Inheritance

Imho, delegation is far easier to maintain. For one thing, you don't need to "cover" all the inherited code you don't need

On Thursday, June 7, 2012, andre wrote:

Thanks for the pointers, Georg. Interesting read.

I see the points, but am inclined to disagree with such a general verdict against MI. There are legitimate uses for it, although it can certainly be abused to create a mess.

Code readability is, and Smalltalkers know that best, a question of the right tools. Plain source "files" are almost always hard to read, no matter which language.

One interesting thing I recently observed concerning the way my thoughts tend to go is, that the typical thought pattern when creating a new class in Smalltak is "of what existing class *is* this object a derivate or specialization?" It is an ontological model. In contrast, the typical thought in C++ is "what is this object supposed to be able to *do*?", which is a behavioral model.

Either model has its advantages and disadvantages. If for example, I have an object that is supposed to be able to

- Run a background thread
- Receive and process jobs from a queue
- Broadcast events to dependent objects
- Provide a server on a network that clients can connect to
- Receive and react to OS events
- Implement application specific behavior that builds on all the above

then using MI, all but the last point could be simply assembled from existing classes. In Smalltalk, I would need to add a lot of protocols and copy/paste/rewrite code from elsewhere.

Delegation is verbose and laborious and hard to maintain. Also if the individual delegates of an object need to share a great deal of common state, things are getting even more laborious.

Andre

_______________________________________________
vwnc mailing list
<a href="javascript:;" onclick="_e(event, 'cvml', 'vwnc@cs.uiuc.edu')">vwnc@...
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Ladislav Lenart

Re: Multiple Inheritance

On 7.6.2012 20:07, James Robertson wrote:
> Imho, delegation is far easier to maintain. For one thing, you don't need to
> "cover" all the inherited code you don't need

Just curious: Why do we use inheritance at all, then? The combo encapsulation +
delegation is sufficient.

Ladislav Lenart

> On Thursday, June 7, 2012, andre wrote:
> Thanks for the pointers, Georg. Interesting read.
>
> I see the points, but am inclined to disagree with such a general verdict
> against MI. There are legitimate uses for it, although it can certainly be
> abused to create a mess.
>
> Code readability is, and Smalltalkers know that best, a question of the
> right tools. Plain source "files" are almost always hard to read, no matter
> which language.
>
> One interesting thing I recently observed concerning the way my thoughts
> tend to go is, that the typical thought pattern when creating a new class in
> Smalltak is "of what existing class *is* this object a derivate or
> specialization?" It is an ontological model. In contrast, the typical
> thought in C++ is "what is this object supposed to be able to *do*?", which
> is a behavioral model.
>
> Either model has its advantages and disadvantages. If for example, I have an
> object that is supposed to be able to
>
> - Run a background thread
> - Receive and process jobs from a queue
> - Broadcast events to dependent objects
> - Provide a server on a network that clients can connect to
> - Receive and react to OS events
> - Implement application specific behavior that builds on all the above
>
> then using MI, all but the last point could be simply assembled from
> existing classes. In Smalltalk, I would need to add a lot of protocols and
> copy/paste/rewrite code from elsewhere.
>
> Delegation is verbose and laborious and hard to maintain. Also if the
> individual delegates of an object need to share a great deal of common
> state, things are getting even more laborious.
>
> Andre
>
>
>
> _______________________________________________
> vwnc mailing list
> [hidden email] <javascript:;>
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
>
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Brad Selfridge

Re: Multiple Inheritance

In reply to this post by jarober

When I worked at Boeing, in Wichita, KS, we had an application that ran the payroll system. The problem was that the application was "one" program. It did everything cause it was the "payroll" process. Turns out the "one" program was over 250,000 lines of code and only the creator was able to understand and make changes to the program. The "one" program was immediately re-written once the creator retired.

I have also seen a lot of Java developers load up a class with many different disparate functions and "scream" in your face stating that they were writing OO code because the language was Java.

I have been writing Smalltalk (mostly) and other OO programs for close to twenty years and I have rarely run into an instance where I wished that I could use MI. I was always able to implement delegation and solve the problem.

It seems to me that the example you provided should be implemented in several classes that is wrapped in an manager class. Not sure MI is the best solution in this instance.

Brad Selfridge

On 6/7/2012 1:07 PM, James Robertson wrote:

Imho, delegation is far easier to maintain. For one thing, you don't need to "cover" all the inherited code you don't need

On Thursday, June 7, 2012, andre wrote:

Thanks for the pointers, Georg. Interesting read.

I see the points, but am inclined to disagree with such a general verdict against MI. There are legitimate uses for it, although it can certainly be abused to create a mess.

Code readability is, and Smalltalkers know that best, a question of the right tools. Plain source "files" are almost always hard to read, no matter which language.

One interesting thing I recently observed concerning the way my thoughts tend to go is, that the typical thought pattern when creating a new class in Smalltak is "of what existing class *is* this object a derivate or specialization?" It is an ontological model. In contrast, the typical thought in C++ is "what is this object supposed to be able to *do*?", which is a behavioral model.

Either model has its advantages and disadvantages. If for example, I have an object that is supposed to be able to

- Run a background thread
- Receive and process jobs from a queue
- Broadcast events to dependent objects
- Provide a server on a network that clients can connect to
- Receive and react to OS events
- Implement application specific behavior that builds on all the above

then using MI, all but the last point could be simply assembled from existing classes. In Smalltalk, I would need to add a lot of protocols and copy/paste/rewrite code from elsewhere.

Delegation is verbose and laborious and hard to maintain. Also if the individual delegates of an object need to share a great deal of common state, things are getting even more laborious.

Andre

_______________________________________________
vwnc mailing list
<a moz-do-not-send="true" href="javascript:;" onclick="_e(event, 'cvml', 'vwnc@cs.uiuc.edu')">vwnc@...
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Brad Selfridge

Björn Eiderbäck-2

Re: Multiple Inheritance

I was a little bit curios about traits in Scala an read a bit in a Scala book. However I thought that it could be a better explanation of the concept. So I search a bit and found that there was some quite early papers on traits that used Smalltalk to describe and examplify it!
O
I just started reading

On Thu, Jun 7, 2012 at 8:40 PM, Brad Selfridge <[hidden email]> wrote:

When I worked at Boeing, in Wichita, KS, we had an application that ran the payroll system. The problem was that the application was "one" program. It did everything cause it was the "payroll" process. Turns out the "one" program was over 250,000 lines of code and only the creator was able to understand and make changes to the program. The "one" program was immediately re-written once the creator retired.

I have also seen a lot of Java developers load up a class with many different disparate functions and "scream" in your face stating that they were writing OO code because the language was Java.

I have been writing Smalltalk (mostly) and other OO programs for close to twenty years and I have rarely run into an instance where I wished that I could use MI. I was always able to implement delegation and solve the problem.

It seems to me that the example you provided should be implemented in several classes that is wrapped in an manager class. Not sure MI is the best solution in this instance.

Brad Selfridge
On 6/7/2012 1:07 PM, James Robertson wrote:
Imho, delegation is far easier to maintain. For one thing, you don't need to "cover" all the inherited code you don't need

On Thursday, June 7, 2012, andre wrote:

Thanks for the pointers, Georg. Interesting read.

I see the points, but am inclined to disagree with such a general verdict against MI. There are legitimate uses for it, although it can certainly be abused to create a mess.

Code readability is, and Smalltalkers know that best, a question of the right tools. Plain source "files" are almost always hard to read, no matter which language.

One interesting thing I recently observed concerning the way my thoughts tend to go is, that the typical thought pattern when creating a new class in Smalltak is "of what existing class *is* this object a derivate or specialization?" It is an ontological model. In contrast, the typical thought in C++ is "what is this object supposed to be able to *do*?", which is a behavioral model.

Either model has its advantages and disadvantages. If for example, I have an object that is supposed to be able to

- Run a background thread
- Receive and process jobs from a queue
- Broadcast events to dependent objects
- Provide a server on a network that clients can connect to
- Receive and react to OS events
- Implement application specific behavior that builds on all the above

then using MI, all but the last point could be simply assembled from existing classes. In Smalltalk, I would need to add a lot of protocols and copy/paste/rewrite code from elsewhere.

Delegation is verbose and laborious and hard to maintain. Also if the individual delegates of an object need to share a great deal of common state, things are getting even more laborious.

Andre

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Björn Eiderbäck-2

Re: Multiple Inheritance

Sorry I managed to push the send button.
But I was about to recommend (but I have just started reading it):

Traits: Composable Units of Behaviour⋆ by Nathanael Scha ̈rli, Ste ́phane Ducasse, Oscar Nierstrasz, and Andrew P. Black

http://www.google.se/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CFkQFjAA&url=http%3A%2F%2Fscg.unibe.ch%2Farchive%2Fpapers%2FScha03aTraits.pdf&ei=0PrQT936D6344QS645imDw&usg=AFQjCNFjNhr_DuVx5vlDWsryTj0TZYfaBA&sig2=RGwyCxnaCxbRVLtp7uDaoQ

They also refer to papers about multiple inheritance.

Best Regards
Björn

On Thu, Jun 7, 2012 at 8:58 PM, Björn Eiderbäck <[hidden email]> wrote:

I was a little bit curios about traits in Scala an read a bit in a Scala book. However I thought that it could be a better explanation of the concept. So I search a bit and found that there was some quite early papers on traits that used Smalltalk to describe and examplify it!
O
I just started reading
On Thu, Jun 7, 2012 at 8:40 PM, Brad Selfridge <[hidden email]> wrote:
When I worked at Boeing, in Wichita, KS, we had an application that ran the payroll system. The problem was that the application was "one" program. It did everything cause it was the "payroll" process. Turns out the "one" program was over 250,000 lines of code and only the creator was able to understand and make changes to the program. The "one" program was immediately re-written once the creator retired.

I have also seen a lot of Java developers load up a class with many different disparate functions and "scream" in your face stating that they were writing OO code because the language was Java.

I have been writing Smalltalk (mostly) and other OO programs for close to twenty years and I have rarely run into an instance where I wished that I could use MI. I was always able to implement delegation and solve the problem.

It seems to me that the example you provided should be implemented in several classes that is wrapped in an manager class. Not sure MI is the best solution in this instance.

Brad Selfridge
On 6/7/2012 1:07 PM, James Robertson wrote:
Imho, delegation is far easier to maintain. For one thing, you don't need to "cover" all the inherited code you don't need

On Thursday, June 7, 2012, andre wrote:

Thanks for the pointers, Georg. Interesting read.

I see the points, but am inclined to disagree with such a general verdict against MI. There are legitimate uses for it, although it can certainly be abused to create a mess.

Code readability is, and Smalltalkers know that best, a question of the right tools. Plain source "files" are almost always hard to read, no matter which language.

One interesting thing I recently observed concerning the way my thoughts tend to go is, that the typical thought pattern when creating a new class in Smalltak is "of what existing class *is* this object a derivate or specialization?" It is an ontological model. In contrast, the typical thought in C++ is "what is this object supposed to be able to *do*?", which is a behavioral model.

Either model has its advantages and disadvantages. If for example, I have an object that is supposed to be able to

- Run a background thread
- Receive and process jobs from a queue
- Broadcast events to dependent objects
- Provide a server on a network that clients can connect to
- Receive and react to OS events
- Implement application specific behavior that builds on all the above

then using MI, all but the last point could be simply assembled from existing classes. In Smalltalk, I would need to add a lot of protocols and copy/paste/rewrite code from elsewhere.

Delegation is verbose and laborious and hard to maintain. Also if the individual delegates of an object need to share a great deal of common state, things are getting even more laborious.

Andre

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Dave Stevenson-3

Re: Multiple Inheritance

In reply to this post by Ladislav Lenart

I would think Brad's point about separating unrelated behaviors into separate classes speaks to 'delegation'. The manager/application object would compose the disparate objects it needs. Inheritance is obviously useful for specializing classes. It could be said that multiple inheritance is not about specialization, but combining specialized classes into a more generalized object.

It is well established that inheritance is a good means of specialization. The argument is whether multiple inheritance is a good choice for generalization, not whether simple inheritance is right for specialization.

Dave Stevenson
[hidden email]

From: Ladislav Lenart <[hidden email]>
To: James Robertson <[hidden email]>
Cc: "[hidden email]" <[hidden email]>; andre <[hidden email]>
Sent: Thu, June 7, 2012 11:28:23 AM
Subject: Re: [vwnc] Multiple Inheritance

On 7.6.2012 20:07, James Robertson wrote:
> Imho, delegation is far easier to maintain. For one thing, you don't need to
> "cover" all the inherited code you don't need

Just curious: Why do we use inheritance at all, then? The combo encapsulation +
delegation is sufficient.

Ladislav Lenart

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

andre

Re: Multiple Inheritance

In reply to this post by Brad Selfridge

Am 07.06.2012 um 20:40 schrieb Brad Selfridge:

> It seems to me that the example you provided should be implemented in several classes that is wrapped in an manager class. Not sure MI is the best solution in this instance.

Yep, one can do that, but it would require all those "several" classes to be subclassed each, because they would have to share a common state with the manager and provide special methods & patterns to do so:

- Subclass the "Thread" thing

- Subclass the "Job Queue" thing

- Subclass the "Broacast" thing

- Subclass the "Server" thing

- Subclass the "OS Events" thing

- Create a "Manager" class that includes instances of all the above.

- Write a lot of code that makes all these objects communicate with each other in order to share a common state.

IMO, that's pretty overkill compared to just clicking LEGO blocks together with MI. Chances are also high that some of the objects may include redundant state information that needs to be synchronized. MI would merge them.

This is really a fundamental problem for which there is no perfect solution. At the end of the day, OO is only an approximation anyway.

Andre

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Brad Selfridge

Re: Multiple Inheritance

It might appear to be overkill until the next poor sap comes along and
says - Gee, I would like to change the behavior of Foo and then realizes
that if he changes Foo he breaks everything else because it's so
inter-linked. I realize that single inheritance, delegation may not
make life easier on the creator, but may make life easier on the poor
schlub that tries to change functionality when the creator is long
gone. I written lots of code (over 30 years) and it's always the
maintenance that's the most expensive, not the creation. I don't know
how many times I've seen software abandoned or re-written because it was
so complex that the developer cannot understand it and therefore is too
scared to change it. My philosophy has always been - "keep is simple".
If I kept it simple, it survived for years - thereby saving the company
a lot of money.

--

Brad Selfridge

On 6/7/2012 3:47 PM, andre wrote:

> Am 07.06.2012 um 20:40 schrieb Brad Selfridge:
>
>> It seems to me that the example you provided should be implemented in several classes that is wrapped in an manager class. Not sure MI is the best solution in this instance.
> Yep, one can do that, but it would require all those "several" classes to be subclassed each, because they would have to share a common state with the manager and provide special methods& patterns to do so:
>
> - Subclass the "Thread" thing
>
> - Subclass the "Job Queue" thing
>
> - Subclass the "Broacast" thing
>
> - Subclass the "Server" thing
>
> - Subclass the "OS Events" thing
>
> - Create a "Manager" class that includes instances of all the above.
>
> - Write a lot of code that makes all these objects communicate with each other in order to share a common state.
>
> IMO, that's pretty overkill compared to just clicking LEGO blocks together with MI. Chances are also high that some of the objects may include redundant state information that needs to be synchronized. MI would merge them.
>
> This is really a fundamental problem for which there is no perfect solution. At the end of the day, OO is only an approximation anyway.
>
> Andre
>
>

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Brad Selfridge

jarober

Re: Multiple Inheritance

In reply to this post by Ladislav Lenart

In general, shallow hierarchies work, deep ones get to be fragile. Good things can be overused. Wrt to MI, there are numerous issues - how the tools work, who "wins" when the same method is inherited from both immediate parents....

On Thursday, June 7, 2012, Ladislav Lenart wrote:

On 7.6.2012 20:07, James Robertson wrote:
> Imho, delegation is far easier to maintain. For one thing, you don't need to
> "cover" all the inherited code you don't need

Just curious: Why do we use inheritance at all, then? The combo encapsulation +
delegation is sufficient.

Ladislav Lenart

> On Thursday, June 7, 2012, andre wrote:
> Thanks for the pointers, Georg. Interesting read.
>
> I see the points, but am inclined to disagree with such a general verdict
> against MI. There are legitimate uses for it, although it can certainly be
> abused to create a mess.
>
> Code readability is, and Smalltalkers know that best, a question of the
> right tools. Plain source "files" are almost always hard to read, no matter
> which language.
>
> One interesting thing I recently observed concerning the way my thoughts
> tend to go is, that the typical thought pattern when creating a new class in
> Smalltak is "of what existing class *is* this object a derivate or
> specialization?" It is an ontological model. In contrast, the typical
> thought in C++ is "what is this object supposed to be able to *do*?", which
> is a behavioral model.
>
> Either model has its advantages and disadvantages. If for example, I have an
> object that is supposed to be able to
>
> - Run a background thread
> - Receive and process jobs from a queue
> - Broadcast events to dependent objects
> - Provide a server on a network that clients can connect to
> - Receive and react to OS events
> - Implement application specific behavior that builds on all the above
>
> then using MI, all but the last point could be simply assembled from
> existing classes. In Smalltalk, I would need to add a lot of protocols and
> copy/paste/rewrite code from elsewhere.
>
> Delegation is verbose and laborious and hard to maintain. Also if the
> individual delegates of an object need to share a great deal of common
> state, things are getting even more laborious.
>
> Andre
>
>
>
> _______________________________________________
> vwnc mailing list
> <a href="javascript:;" onclick="_e(event, 'cvml', 'vwnc@cs.uiuc.edu')">vwnc@... <javascript:;>
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
>
>
> _______________________________________________
> vwnc mailing list
> <a href="javascript:;" onclick="_e(event, 'cvml', 'vwnc@cs.uiuc.edu')">vwnc@...
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Terry Raymond

Re: Multiple Inheritance

In reply to this post by andre

If I understand you correctly, a class that is a thread thing and a job
queue thing, etc., is
overloaded. When you ask a class what it is it should respond as one thing,
not a hydra thing.

MI should only add attributes and the behavior to support those attributes
and the attributes
should be related to the core responsibility of the class.

A couple of simple goals to remember; a method should do only one thing, and
its code should
be written at one level of abstraction; a class should be responsible for
only one functional area.
If a class has a large responsibility then it should delegate to components
and each of them should
provide a single area of responsibility.

Terry

===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI 02878
(401) 624-4517 [hidden email]
===========================================================

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of andre
> Sent: Thursday, June 07, 2012 4:48 PM
> To: Brad Selfridge
> Cc: VWNC list
> Subject: Re: [vwnc] Multiple Inheritance
>
>
> Am 07.06.2012 um 20:40 schrieb Brad Selfridge:
>
> > It seems to me that the example you provided should be implemented in
> several classes that is wrapped in an manager class. Not sure MI is the

best
> solution in this instance.
>
> Yep, one can do that, but it would require all those "several" classes to
be

> subclassed each, because they would have to share a common state with the
> manager and provide special methods & patterns to do so:
>
> - Subclass the "Thread" thing
>
> - Subclass the "Job Queue" thing
>
> - Subclass the "Broacast" thing
>
> - Subclass the "Server" thing
>
> - Subclass the "OS Events" thing
>
> - Create a "Manager" class that includes instances of all the above.
>
> - Write a lot of code that makes all these objects communicate with each
> other in order to share a common state.
>
> IMO, that's pretty overkill compared to just clicking LEGO blocks together
> with MI. Chances are also high that some of the objects may include
> redundant state information that needs to be synchronized. MI would merge
> them.
>
> This is really a fundamental problem for which there is no perfect

solution. At
> the end of the day, OO is only an approximation anyway.
>
> Andre
>
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Niall Ross

Re: Multiple Inheritance

In reply to this post by andre

Dear Andre,
the only time I've ever wanted multiple inheritance, or at least
mixins, is when implementing a meta-data framework. Some state is
required, so stateless traits don't cover this case.

There was a discussion of this case at ESUG 2005 in Brussels, recorded
on page 55 of the report:

http://www.esug.org/data/ReportsFromNiallRoss/nfrESUG2005report.pdf

So perhaps I don't quite agree with those who say it is never needed,
but my experience is that it is rarely needed. Thus I'd agree on
keeping it out of the base, though happy to see the framework Georg
suggested, or similar, available to load as a prereq of specific
applications.

I'd guess another legitimate use would be when porting a system where MI
has been used to Smalltalk (I've never had occasion to do that myself).

Yours faithfully
Niall Ross

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Nowak, Helge

Re: Multiple Inheritance

There used to be an MI framework for VisualWorks available from Applied Reasoning till the late 90-ies. It had been developed by Bill Burdick who - according to LinkedIn - runs today his own company "Mobile Reasoning". Maybe you want to contact him for his opinion and solution.

Interesting is also to look at why Java and C# don't have multiple inheritance. See a discussion here: http://stackoverflow.com/questions/995255/why-is-multiple-inheritance-not-allowed-in-java-or-c
Or, more academic, this paper: http://www.cs.wright.edu/~tkprasad/papers/mi.pdf

HTH
Helge

-----Ursprüngliche Nachricht-----
Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Niall Ross
Gesendet: Freitag, 8. Juni 2012 15:23
An: andre
Cc: VWNC list
Betreff: Re: [vwnc] Multiple Inheritance

Dear Andre,
the only time I've ever wanted multiple inheritance, or at least mixins, is when implementing a meta-data framework. Some state is required, so stateless traits don't cover this case.

There was a discussion of this case at ESUG 2005 in Brussels, recorded on page 55 of the report:

http://www.esug.org/data/ReportsFromNiallRoss/nfrESUG2005report.pdf

So perhaps I don't quite agree with those who say it is never needed, but my experience is that it is rarely needed. Thus I'd agree on keeping it out of the base, though happy to see the framework Georg suggested, or similar, available to load as a prereq of specific applications.

I'd guess another legitimate use would be when porting a system where MI has been used to Smalltalk (I've never had occasion to do that myself).

Yours faithfully
Niall Ross

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Paul Baumann

Re: Multiple Inheritance

Rebecca Wirfs-Brock had given an on-site Smalltalk training session back around 1994 in which she gave a good example of where single inheritance breaks down. Her example involved classifying kitchen utensils. Single inheritance quickly broke down and duplication was one escape. MI would have solved the problem if it existed for Smalltalk.

MI frameworks are an ideal that maximizes code reuse. In my experience, I've seen people make too many mistakes with SI to think they would possibly do a good job with MI. Even more though, most programmers are application developers that have absolutely no reservations about copying behavior. Code reuse happens when code is refactored, and most development managers of that era exaggerated the risks of refactoring "working" code to make it more maintainable.

Sometime after Rebecca's course I developed a mixin framework for VAST (which was called ENVY/400 at that time). The framework worked excellent but for ultimate performance it relied on a few tricks that few people would attempt. Inherited behavior (that was not explicit) fell to #doesNotUnderstand: (as most mixin frameworks do) but the framework would then insert a special pattern method into the method dictionary to optimize for subsequent sends. The tricky part about doing this is that code management tools handle these special methods correctly. The mixin framework worked well and I made it public domain for others to use. As simple as it was, there was a learning curve for new users. Eventually I stopped using it myself due to the overwhelming reistance to refactoring at that time.

Other people created MI and mixin frameworks for Smalltalk around that time too. I suspect they had the same experience as I had. Perhaps it would be more accepted today now that refactoring is acceptable. Even today though, people just copy code and do not care about future maintainability. SI is good enough for most development and people don't tend to notice when it fails because by that time they want to rewrite all the code anyway.

Paul Baumann

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Nowak, Helge
Sent: Friday, June 08, 2012 10:22
To: Niall Ross; andre
Cc: VWNC list
Subject: Re: [vwnc] Multiple Inheritance

There used to be an MI framework for VisualWorks available from Applied Reasoning till the late 90-ies. It had been developed by Bill Burdick who - according to LinkedIn - runs today his own company "Mobile Reasoning". Maybe you want to contact him for his opinion and solution.

Interesting is also to look at why Java and C# don't have multiple inheritance. See a discussion here: http://stackoverflow.com/questions/995255/why-is-multiple-inheritance-not-allowed-in-java-or-c
Or, more academic, this paper: http://www.cs.wright.edu/~tkprasad/papers/mi.pdf

HTH
Helge

-----Ursprüngliche Nachricht-----
Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Niall Ross
Gesendet: Freitag, 8. Juni 2012 15:23
An: andre
Cc: VWNC list
Betreff: Re: [vwnc] Multiple Inheritance

Dear Andre,
the only time I've ever wanted multiple inheritance, or at least mixins, is when implementing a meta-data framework. Some state is required, so stateless traits don't cover this case.

There was a discussion of this case at ESUG 2005 in Brussels, recorded on page 55 of the report:

http://www.esug.org/data/ReportsFromNiallRoss/nfrESUG2005report.pdf

So perhaps I don't quite agree with those who say it is never needed, but my experience is that it is rarely needed. Thus I'd agree on keeping it out of the base, though happy to see the framework Georg suggested, or similar, available to load as a prereq of specific applications.

I'd guess another legitimate use would be when porting a system where MI has been used to Smalltalk (I've never had occasion to do that myself).

Yours faithfully
Niall Ross

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Stephen Pope

Re: Multiple Inheritance

Thank you all for this thread.

I've worked a lot with both SI and MI languages, and have to go way back to Georg Heeg's initial comment that the desire for MI shows weak design, and politely but firmly disagree.

I want to develop in a language that has many ways to combine and share state and behavior, and claim that it you look through the design patterns literature, you'll find patterns that suggest using MI, others that call out for 2-step double-dispatching, and still others that suggest traits or interfaces. The basic sharing relationships are something like:

Basic composition & delegation
Double-dispatching
SI
MI
Prototypes/Traits
Mix-in-style MI
Interfaces

I sure wish my Smalltalk had MI and formal Interfaces (enforced mix-in classes).

The second issue is the design of core libraries for OOPS. The early attempts in true MI design for core data types (Magnitudes. Collections and Streams) were Flavors LISP and INTERLISP, and both evolved into systems with thousands of tiny mix-in classes and a really complicated namespace. This doesn't mean that you couldn't have a simple, SI-centric core library like Smalltalk's in a language with MI and formal interfaces.

As a separate point, mix-in-style MI is *quite* useful for several design patterns such as composite, singleton, visitor and decorator. It could well be used (judiciously) in the Smalltalk core library.

stp

--

Stephen Travis Pope Santa Barbara, California, USA http://HeavenEverywhere.com

-

On Jun 8, 2012, at 9:31 AM, Paul Baumann wrote:

> Rebecca Wirfs-Brock had given an on-site Smalltalk training session back around 1994 in which she gave a good example of where single inheritance breaks down. Her example involved classifying kitchen utensils. Single inheritance quickly broke down and duplication was one escape. MI would have solved the problem if it existed for Smalltalk.
>
> MI frameworks are an ideal that maximizes code reuse. In my experience, I've seen people make too many mistakes with SI to think they would possibly do a good job with MI. Even more though, most programmers are application developers that have absolutely no reservations about copying behavior. Code reuse happens when code is refactored, and most development managers of that era exaggerated the risks of refactoring "working" code to make it more maintainable.
>
> Sometime after Rebecca's course I developed a mixin framework for VAST (which was called ENVY/400 at that time). The framework worked excellent but for ultimate performance it relied on a few tricks that few people would attempt. Inherited behavior (that was not explicit) fell to #doesNotUnderstand: (as most mixin frameworks do) but the framework would then insert a special pattern method into the method dictionary to optimize for subsequent sends. The tricky part about doing this is that code management tools handle these special methods correctly. The mixin framework worked well and I made it public domain for others to use. As simple as it was, there was a learning curve for new users. Eventually I stopped using it myself due to the overwhelming reistance to refactoring at that time.
>
> Other people created MI and mixin frameworks for Smalltalk around that time too. I suspect they had the same experience as I had. Perhaps it would be more accepted today now that refactoring is acceptable. Even today though, people just copy code and do not care about future maintainability. SI is good enough for most development and people don't tend to notice when it fails because by that time they want to rewrite all the code anyway.
>
> Paul Baumann
>
>
>
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Nowak, Helge
> Sent: Friday, June 08, 2012 10:22
> To: Niall Ross; andre
> Cc: VWNC list
> Subject: Re: [vwnc] Multiple Inheritance
>
> There used to be an MI framework for VisualWorks available from Applied Reasoning till the late 90-ies. It had been developed by Bill Burdick who - according to LinkedIn - runs today his own company "Mobile Reasoning". Maybe you want to contact him for his opinion and solution.
>
> Interesting is also to look at why Java and C# don't have multiple inheritance. See a discussion here: http://stackoverflow.com/questions/995255/why-is-multiple-inheritance-not-allowed-in-java-or-c
> Or, more academic, this paper: http://www.cs.wright.edu/~tkprasad/papers/mi.pdf
>
> HTH
> Helge
>
> -----Ursprüngliche Nachricht-----
> Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Niall Ross
> Gesendet: Freitag, 8. Juni 2012 15:23
> An: andre
> Cc: VWNC list
> Betreff: Re: [vwnc] Multiple Inheritance
>
> Dear Andre,
> the only time I've ever wanted multiple inheritance, or at least mixins, is when implementing a meta-data framework. Some state is required, so stateless traits don't cover this case.
>
> There was a discussion of this case at ESUG 2005 in Brussels, recorded on page 55 of the report:
>
> http://www.esug.org/data/ReportsFromNiallRoss/nfrESUG2005report.pdf
>
> So perhaps I don't quite agree with those who say it is never needed, but my experience is that it is rarely needed. Thus I'd agree on keeping it out of the base, though happy to see the framework Georg suggested, or similar, available to load as a prereq of specific applications.
>
> I'd guess another legitimate use would be when porting a system where MI has been used to Smalltalk (I've never had occasion to do that myself).
>
> Yours faithfully
> Niall Ross
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
>
> This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.
>
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

pastedGraphic.tiff (3K) Download Attachment

Conrad Taylor

Re: Multiple Inheritance

In reply to this post by Paul Baumann

On Fri, Jun 8, 2012 at 9:31 AM, Paul Baumann <[hidden email]> wrote:

Rebecca Wirfs-Brock had given an on-site Smalltalk training session back around 1994 in which she gave a good example of where single inheritance breaks down. Her example involved classifying kitchen utensils. Single inheritance quickly broke down and duplication was one escape. MI would have solved the problem if it existed for Smalltalk.

Paul, do you have any more information about the example that Rebecca Wirfs-Brock had given?

MI frameworks are an ideal that maximizes code reuse. In my experience, I've seen people make too many mistakes with SI to think they would possibly do a good job with MI. Even more though, most programmers are application developers that have absolutely no reservations about copying behavior. Code reuse happens when code is refactored, and most development managers of that era exaggerated the risks of refactoring "working" code to make it more maintainable.

Sometime after Rebecca's course I developed a mixin framework for VAST (which was called ENVY/400 at that time). The framework worked excellent but for ultimate performance it relied on a few tricks that few people would attempt. Inherited behavior (that was not explicit) fell to #doesNotUnderstand: (as most mixin frameworks do) but the framework would then insert a special pattern method into the method dictionary to optimize for subsequent sends. The tricky part about doing this is that code management tools handle these special methods correctly. The mixin framework worked well and I made it public domain for others to use. As simple as it was, there was a learning curve for new users. Eventually I stopped using it myself due to the overwhelming reistance to refactoring at that time.

Other people created MI and mixin frameworks for Smalltalk around that time too. I suspect they had the same experience as I had. Perhaps it would be more accepted today now that refactoring is acceptable. Even today though, people just copy code and do not care about future maintainability. SI is good enough for most development and people don't tend to notice when it fails because by that time they want to rewrite all the code anyway.

Paul Baumann

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Nowak, Helge
Sent: Friday, June 08, 2012 10:22
To: Niall Ross; andre
Cc: VWNC list
Subject: Re: [vwnc] Multiple Inheritance

There used to be an MI framework for VisualWorks available from Applied Reasoning till the late 90-ies. It had been developed by Bill Burdick who - according to LinkedIn - runs today his own company "Mobile Reasoning". Maybe you want to contact him for his opinion and solution.

Interesting is also to look at why Java and C# don't have multiple inheritance. See a discussion here: http://stackoverflow.com/questions/995255/why-is-multiple-inheritance-not-allowed-in-java-or-c
Or, more academic, this paper: http://www.cs.wright.edu/~tkprasad/papers/mi.pdf

HTH
Helge

-----Ursprüngliche Nachricht-----
Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Niall Ross
Gesendet: Freitag, 8. Juni 2012 15:23
An: andre
Cc: VWNC list
Betreff: Re: [vwnc] Multiple Inheritance

Dear Andre,
the only time I've ever wanted multiple inheritance, or at least mixins, is when implementing a meta-data framework. Some state is required, so stateless traits don't cover this case.

There was a discussion of this case at ESUG 2005 in Brussels, recorded on page 55 of the report:

http://www.esug.org/data/ReportsFromNiallRoss/nfrESUG2005report.pdf

So perhaps I don't quite agree with those who say it is never needed, but my experience is that it is rarely needed. Thus I'd agree on keeping it out of the base, though happy to see the framework Georg suggested, or similar, available to load as a prereq of specific applications.

I'd guess another legitimate use would be when porting a system where MI has been used to Smalltalk (I've never had occasion to do that myself).

Yours faithfully
Niall Ross

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Think different and code well,

-Conrad

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Paul Baumann

Re: Multiple Inheritance

My recollection is...

It was about how to classify objects (kitchen utensils in this case). She asked the class to name all the utensils they could think of. Each was written on an index card. http://en.wikipedia.org/wiki/List_of_food_preparation_utensils. She asked for ideas about how they might be classified (by material, use, location of use, stage of use, context of use, etc.). There was discussion and disagreement of course. Attributes of each were added to each card. The attributes helped some (by defining a classification epistemology). Though classification rules were now defined, utensils still failed to be conform in a way that supports single inheritance. Would a "spork" be a kind of fork or spoon? With SI, you can only pick one. Should a new kind of abstract utensil class be created to accommodate the spork? Still then, what is the superclass of a spork? Neither would be ideal and behavior for the other class would have to be copied to the Spork.

This is when she introduced the notion of multiple inheritance and that Smalltalk doesn't have it (C++ started to seem cool for a moment). But what could be done for Smalltalk though? The answer was to define a hierarchy of responsibilities (each with attributes and behavior). A Spork would then be defined as a combination of responsibilities/abstractions that were bridged together and yet still behaved as a class for which instances could be created. Spork was neither a subclass of fork nor spoon but shared the same superclass. The hierarchy of utensil classes could become shallower and more manageable as two separate hierarchies. Separation into two hierarchies of responsibility (that are bridged together) was more maintainable than a pure MI approach. All that Smalltalk needed was a simple framework to allow classes to be defined as a mixture of the behavior of other classes.

A mixin framework can be described as support for the automatic maintenance of mixed-in responsibilities to reduce the redundancy that normally evolves from SI. A mixin framework is a tool to help a developer increase code reuse and reduce code maintenance costs.

I had set about to implement a framework to make this easy to manage. At first I called it a Multiple Inheritance framework. Then later renamed code to use either "mixin" or "pidgin" once I saw that those terms seemed to have already been established for use in other languages. The terms were not familiar to many though. Delegation of behavior was the easy part to implement; the trickier issues were around attribute implementation and preservation of "self". I used template compiled methods that were copied with modification directly into the method dictionary. In one implementation, "self" was preserved through #== checks on the results from forwarded messages. The sequence of inherited behaviors defined behavior inheritance priority. If Spork was defined with responsibility of first Spoon and then Fork then a common method like #printOn: would by default to that of Spoon. Spork could of course define #printOn: a more appropriate way while still being able to explicitly call the behavior inherited from Spoon or Fork. I'd experimented with other implementation variations too (things like associated attributes and automatic local copies of behavior). An implementation I settled on had an array of instances of inherited responsibilities for which methods were configured to access the correct index position. It was the responsibility of the framework to automatically keep all inherited behavior and references in sync as code evolved. It worked well, but had tricks so that code management tools like ENVY would not get confused. Another tricky area was in related to inheritance from classes (like Date and Float) that aren't created (and initialized) like most other objects.

The idea at the time was to encourage Smalltalk vendors to adopt an implementation as standard. That started to happen but those that developed interest always wanted to start their own implementation from scratch and just did the #doesNotUnderstand: tricks alone and later gave up when preservation of "self" became recognized as a challenge. That was one of my first experiences with attempting to help evolve the Smalltalk language. The cultural challenges never got much better. For better and worse, Smalltalk is a closed language that evolves or dies by the choices of a few vendors and from the inspiration of a few employed by those vendors. Lacking a market that could develop a financial incentive, the only motivation that exists for frameworks like this is personal pride of accomplishment. That is why every Smalltalker "re-invents the wheel" and also why really good frameworks rarely get shared or used. Smalltalk development is a culture of one.

GS/S and now VisualWorks have the ability to associate state directly to instances (without the traditional trick of weak reference lookup tables). Features like this can make for more efficient mixin frameworks that can preserve "self" easier than the ones I'd implemented. Hopefully someone will leverage this new feature to establish a good mixin framework that we will all use.

Paul Baumann

From: Conrad Taylor [mailto:[hidden email]]
Sent: Monday, June 11, 2012 03:00
To: Paul Baumann
Cc: Nowak, Helge; Niall Ross; andre; VWNC list
Subject: Re: [vwnc] Multiple Inheritance

On Fri, Jun 8, 2012 at 9:31 AM, Paul Baumann <[hidden email]> wrote:

Rebecca Wirfs-Brock had given an on-site Smalltalk training session back around 1994 in which she gave a good example of where single inheritance breaks down. Her example involved classifying kitchen utensils. Single inheritance quickly broke down and duplication was one escape. MI would have solved the problem if it existed for Smalltalk.

Paul, do you have any more information about the example that Rebecca Wirfs-Brock had given?

MI frameworks are an ideal that maximizes code reuse. In my experience, I've seen people make too many mistakes with SI to think they would possibly do a good job with MI. Even more though, most programmers are application developers that have absolutely no reservations about copying behavior. Code reuse happens when code is refactored, and most development managers of that era exaggerated the risks of refactoring "working" code to make it more maintainable.

Sometime after Rebecca's course I developed a mixin framework for VAST (which was called ENVY/400 at that time). The framework worked excellent but for ultimate performance it relied on a few tricks that few people would attempt. Inherited behavior (that was not explicit) fell to #doesNotUnderstand: (as most mixin frameworks do) but the framework would then insert a special pattern method into the method dictionary to optimize for subsequent sends. The tricky part about doing this is that code management tools handle these special methods correctly. The mixin framework worked well and I made it public domain for others to use. As simple as it was, there was a learning curve for new users. Eventually I stopped using it myself due to the overwhelming reistance to refactoring at that time.

Other people created MI and mixin frameworks for Smalltalk around that time too. I suspect they had the same experience as I had. Perhaps it would be more accepted today now that refactoring is acceptable. Even today though, people just copy code and do not care about future maintainability. SI is good enough for most development and people don't tend to notice when it fails because by that time they want to rewrite all the code anyway.

Paul Baumann

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Nowak, Helge
Sent: Friday, June 08, 2012 10:22
To: Niall Ross; andre
Cc: VWNC list
Subject: Re: [vwnc] Multiple Inheritance

There used to be an MI framework for VisualWorks available from Applied Reasoning till the late 90-ies. It had been developed by Bill Burdick who - according to LinkedIn - runs today his own company "Mobile Reasoning". Maybe you want to contact him for his opinion and solution.

Interesting is also to look at why Java and C# don't have multiple inheritance. See a discussion here: http://stackoverflow.com/questions/995255/why-is-multiple-inheritance-not-allowed-in-java-or-c
Or, more academic, this paper: http://www.cs.wright.edu/~tkprasad/papers/mi.pdf

HTH
Helge

-----Ursprüngliche Nachricht-----
Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Niall Ross
Gesendet: Freitag, 8. Juni 2012 15:23
An: andre
Cc: VWNC list
Betreff: Re: [vwnc] Multiple Inheritance

Dear Andre,
the only time I've ever wanted multiple inheritance, or at least mixins, is when implementing a meta-data framework. Some state is required, so stateless traits don't cover this case.

There was a discussion of this case at ESUG 2005 in Brussels, recorded on page 55 of the report:

http://www.esug.org/data/ReportsFromNiallRoss/nfrESUG2005report.pdf

So perhaps I don't quite agree with those who say it is never needed, but my experience is that it is rarely needed. Thus I'd agree on keeping it out of the base, though happy to see the framework Georg suggested, or similar, available to load as a prereq of specific applications.

I'd guess another legitimate use would be when porting a system where MI has been used to Smalltalk (I've never had occasion to do that myself).

Yours faithfully
Niall Ross

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Think different and code well,

-Conrad

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc