Provide working code in the language of your choice that demonstrates a
problem that is better served by multiple inheritance than single
inheritance and you will have proven your point.
I believe I had explained enough. If it's about examples there are many
around the web. If one is interested to know more about the advantages
of having multiple inheritance there certainly are many around the web.
It's not that I can't prove anything. I already encountered two
situations twice and both were related to inheriting an external class
where one of the other parent class was already a working class - that
which could have solved things simpler and easier if MI was possible.
Come to think of it I could actually give you a summary of those
classes.
And this time this was not possible. I now have to decide whether I have
to merge all codes from Updater to DaemonUpdater to make it work with
ServiceUpdater or use another Class to Inherit Daemon that would control
ServiceUpdater which would really be a hassle design-wise. No matter how
you look at multi-inheritance would be the easiest form. Other
variations would be just workarounds or redundant forms.
Now please reconsider again if you're going to question if my analogy
with respect to the matter wasn't really that deep that there could have
been something I missed for you to question me again. This is also just
an example. An enough proof of concept as I could see it.
Peter Hickman wrote in post #1082774:
> Provide working code in the language of your choice that demonstrates a
> problem that is better served by multiple inheritance than single
> inheritance and you will have proven your point.
I believe I had explained enough. If it's about examples there are many
around the web.
I have googled and cannot find an example of a problem that is better
served by multiple inheritance than single inheritance. If you know of one
then I would be grateful if you could provide the url.
If one is interested to know more about the advantages
of having multiple inheritance there certainly are many around the web.
Now you are avoiding the question. I am well aware of the advantages of
multiple inheritance, that is not what I asked. What I asked for was
"a problem that is better served by multiple inheritance than
single inheritance". You have not provided one and therefore any hand
wavy arguments you put forward only serve to convince me that you do not
know of even a single instance.
It's not that I can't prove anything.
Good, then show me the code.
Come to think of it I could actually give you a summary of those
classes.
Again with the hand waving. Without seeing the code I am unable to see how
this could be refactored to make it easily implemented with single
inheritance. Likewise I cannot see how difficult it might be and go "oh
he's right, this would be easier with multiple inheritance".
Of course I could just take you word for it ... never gonna happen
···
On 4 November 2012 16:55, Ross Konsolebox <lists@ruby-forum.com> wrote:
As a general principles, multiple inheritance can be replaced by
modules+mix-in.
And this time this was not possible. I now have to decide whether I have
to merge all codes from Updater to DaemonUpdater to make it work with
ServiceUpdater or use another Class to Inherit Daemon that would control
ServiceUpdater which would really be a hassle design-wise. No matter how
you look at multi-inheritance would be the easiest form. Other
variations would be just workarounds or redundant forms.
It might be "work around". But you have to pay the price of
inheritance graph complexity and resolving conflicts anyway.
Do you fully understand C3 algorithm that CLOS uses to resolve
multiple inheritance priority order. I don't. That's one of the
reason I didn't put multiple inheritance in to Ruby.
So, you have options. a) Use mix-ins, compromising "work around".
b) just go to a language with multiple inheritance.
matz.
···
In message "Re: Support for multiple Inheritance by classes" on Mon, 5 Nov 2012 01:55:36 +0900, Ross Konsolebox <lists@ruby-forum.com> writes: