On Wed, 24 Oct 2001, Sean L. Palmer wrote:

> enables both these things, but they're both unnecessary.  MI is appealing conceptually, until you've had to throw away a few spaghetti projects because you couldn't disentangle them.


If you really want to know an elegant MI design, please read this tutorial page:

	http://www.eiffel.com/doc/online/eiffel50/intro/language/tutorial-10.html#pgfId-515052

It's not a very long page, please do take a few minutes to read, particularly about the keywords :'rename', 'export', 'undefine', 'redefine' and 'select'. And then go back to your questions and see if you're convinced (pay close attention to the section: "Repeated inheritance and selection").

The answer has already been there for years, only if people care to read.


BTW, the data persistence machinism of Eiffel is also something I'd like to see in D:  'store' and 'retrieve' the whole object structure starting from a root object to either a disk file or a network connection (by taking into account of reference sharing and circlarity).  Even better, the deep_clone gives you a deep copy of the whole object structure in the memory.

Hi, Walter, you didn't give much detail about the data persistence machinism of D online.  Have you got any plan about it yet?

A final question will be, when will the compiler be ready for download? :-)

> Say you have this situation:
>
> class A {}
> class B : A {}
> class C : A {}
> class D : B, C {}
>
> Now how many instances of A are in D?  Two?  Or one... but which one, the one from B or the one from C?  What if both B and C try to use the same A? Will it behave ok, or will it be a bug?  Can you tell the compiler which one to keep, or to merge the two, or to keep both and have duplicate, possibly conflicting data?  How do clients figure out how to get a pointer to the A part of a D?

I *sincerely* urge you to read the following page to find an clean (and fully programmer-controllable) solution for your questions:

	http://www.eiffel.com/doc/online/eiffel50/intro/language/tutorial-10.htm
l#pgfId-515052


> > Suppose classes A and B both define foo().  C inherits from both A and B, which one do you inherit?  What if foo() in A and B were redefined from a common ancestor, Z?  What if one of them is final?  There's just too much to think about.

See above, please read :

	http://www.eiffel.com/doc/online/eiffel50/intro/language/tutorial-10.htm
l#pgfId-515052

> There is runtime overhead for the solution C++ came up with to allow one to specify that the compiler should merge the A's together.
>
> MI really just opens up a whole can of worms that is just better left closed.  I've argued the opposite point too, years ago, but lately I really

It's only because C++'s ugly implementation of MI.  And because C++ is such a popular language (unfortunately), most people's way of thinking is brain-washing by C++.   There are life beyond C++, if you are serious about MI, PLEASE READ:

      	http://www.eiffel.com/doc/online/eiffel50/intro/language/tutorial-10.htm
l#pgfId-515052

And check again if your above questions are solved cleanly.


P.S.

If you do not know Eiffel before, the 'anchored type' is also very interesting, something one can only dreamed of in a C++/Java controlled world.

Diamond MI:
			A
		       / \
		      /   \
		    B       C
		     \     /
		      \  /
			D

Eiffel's solution:

rename:		change the name of a method

export:		change the accessibility of a method

undefine:	keep the method name and signature, but undefine the
		method body (or in C++'s term, change it to an abstract
		pure virtual func)

redefine:	(in C++: virtual, because Eiffel won't implicitly
		override)

select:		select one of the repeatedly inherited methods.


default behavior:	merged (shared)


So in Eiffel you can even *safely* write:

	class   B
	inherit A  ...
		A  ...
		A  ...
		end


Something you won't able to do in C++.


P.S.
(This is yqz@comlab.ox.ac.uk, I'm using my friend's E-mail account.)

	Frankly, I don't think your idea will make it in, at least not any time
soon.  The decision seems to have already been made.  I am curious what
the `default` behavior actually does?  Merge sounds a bit odd.
	To be honest, it sounds like this could make call forwarding/delegation
very easy.  It's as if the parent classes are almost member data, the
apropriate methods are defined to forward as specified and the class
signature is updated.  It sounds like it could be straight forward
enough.  I still thinkk it won't happen in this language.  There is a
bit of an anti-MI support group going here.
	I'm afraid I could not read the page you gave.  One message had bad
URLs and the other message had a reference to a page that does not
render well in my browser.  It's kind of funny actually.  By the time
you reach the bottom of the page the text is so large that only two
lines will fit on the screen, and the word "Engineering," takes up the
entire width of the screen.

Dan

xiaochuang ling wrote:
> 
> Diamond MI:
>                         A
>                        / \
>                       /   \
>                     B       C
>                      \     /
>                       \  /
>                         D
> 
> Eiffel's solution:
> 
> rename:         change the name of a method
> 
> export:         change the accessibility of a method
> 
> undefine:       keep the method name and signature, but undefine the
>                 method body (or in C++'s term, change it to an abstract
>                 pure virtual func)
> 
> redefine:       (in C++: virtual, because Eiffel won't implicitly
>                 override)
> 
> select:         select one of the repeatedly inherited methods.
> 
> default behavior:       merged (shared)
> 
> So in Eiffel you can even *safely* write:
> 
>         class   B
>         inherit A  ...
>                 A  ...
>                 A  ...
>                 end
> 
> Something you won't able to do in C++.
> 
> P.S.
> (This is yqz@comlab.ox.ac.uk, I'm using my friend's E-mail account.)

> 	I'm afraid I could not read the page you gave.

First go to :

http://www.eiffel.com/doc/online/eiffel50/intro/language/tutorial-00.html

Then click on Section 9.

xiaochuang ling wrote:
> 
> >       I'm afraid I could not read the page you gave.
> 
> First go to :
> 
> http://www.eiffel.com/doc/online/eiffel50/intro/language/tutorial-00.html
> 
> Then click on Section 9.

Same problem.  I must have an out of date version of netscape.

Dan

> Same problem.  I must have an out of date version of netscape.

Even with the latest Netscape, you may still have problem :-)  Many web-pages these days only *support* (I mean it) M$'s IE.  On the other hand, Netscape is quite buggy.

Maybe you can try opera, if you don't like the fatty IE.

	http://www.opera.com/

It's small, fast, up-to-date, FREE; and runs on both Win32 and Linux.

(Sorry, this is off-topic on this D-list.)