August 30, 2001
> Now, if anyone has a good way of resolving conflicts (I hear Eiffel is good at that) I think we'd all be willing to hear it.  But disallowing conflicts shouldn't affect the compiler too much (it just fills in the vtable it was going to leave blank), and it gives ua a nice feature to play with.
> 
> Comments on that?

I agree completly, I had no problems implementing MI for my compiler, I simply forbidded conflict and it I've no problems with it. I don't know why all people damm MI, just because C++ was so a bad implementation of it.

In my opinion interfaces are just a workaround around missing MI. I know java puriest will say it isn't, but I believe it is. Especially as in java you've always classes comming in double, as interface and as empty object for inheritince it shows it weakness. Like all the InputListeners, you either can use an default Listener only overriding the functions you're interested in, or you must implement the whole interface sometimes necesarry because you inherit already from something else. Resulting have dozends of meaninlings code lines, just because java wants it so. I think interfaces are just a lame excuse for not having MI.

- Axel

August 30, 2001
> The compiler exists, but is a bit buggy. The runtime library is a bit
> embryonic. The other tools - linker, make, etc., are all done & mature since they come from the C/C++ compiler.
> 
> I'm currently working on building a better garbage collector.

Are you the only one working on the project?  If not, how many others are working on the project?

Is "D" going to be closed-source or open-source?

How far is the project expected to take "D" - into the commercial arena?  or specifically a hobby language?
-- 

Michael Lee Yohe (myohe+USENET@redhat.com)
Software Developer, Engineering Services
Red Hat, Inc.

QUIPd 0.12:
-> You might say that Perl allows you to be paradigmatic
-> without being "paradogmatic".
-> - Larry Wall

August 31, 2001
Michael Lee Yohe wrote:

> Is "D" going to be closed-source or open-source?

D is a language spec.  Walter has specifically stated previously that if someone want to write the appropriate stuff to allow gcc to compile D, then he's all for it.

Chris
August 31, 2001
Michael Lee Yohe wrote in message <3B8EA865.2030105@redhat.com>...
>> The compiler exists, but is a bit buggy. The runtime library is a bit embryonic. The other tools - linker, make, etc., are all done & mature since they come from the C/C++ compiler.
>>
>> I'm currently working on building a better garbage collector.
>
>Are you the only one working on the project?  If not, how many others are working on the project?
>
>Is "D" going to be closed-source or open-source?
>
>How far is the project expected to take "D" - into the commercial arena?
>  or specifically a hobby language?


Hobby? No way. I have no time for hobbies <g>. I've done several professional compilers from scratch, so I think I know what I'm doing there. I would like for there to be a free version of the compiler, and I expect most of the libraries to be open source. The mechanics of all this needs to be worked out.

But first things first - I have to get the language spec about 90% complete and a solid compiler implementing it.


August 31, 2001
Eric Gerlach wrote:
> Here's my thought:  What about allowing MI, as long as there are *no* conflicts?  None.  Whatsoever.  If there are, it's an error.  That allows the useful part of MI without getting into the mess.

	Frankly, I find this hyper-idealist.  It sounds good, but the cases I
care about most is inheriting from class I didn't write.  I don't want
to rewrite the code as an interface and copy the implementations.  I
don't want to rewrite them because the both have a toString function.
Let me write my own or address the conflict.  I suppose I can agree to
forcing conflicts to being resolved in the inheriting class so the
compiler is left trying to guess, but I would rather have the total
deficiency than to have a solution that is too idealized to be of any
practical value.

Dan
August 31, 2001
Walter wrote:
> Unfortunately, the helper class is the way to factor out the common code.

	That is assuming that you wrote A and can hence rewrite it as an
interface and helper.  Convenience (or a lack there of) aside, you are
in trouble if the vendor shipped a class.

> Another way is to embed an instance of A as a member of Y and Z. -Walter

	At least with the helper (assuming you can do it) you get polymorphism
and an error if a new method gets added to the interface.  This is a
punt.

Dan
September 01, 2001
Dan Hursh wrote in message <3B8DD17F.CAD2F377@infonet.isl.net>...
>Walter wrote:
>> The way to do it is to use interfaces:
>>     class Car : Vehicle, Idable
>>     {
>>     }
>> Base classes after the first base class are interface classes.
>Now I'm confused.  Can a class inherit implementation code from an interface?

No. An interface is just a function declaration, no code.

>If so then I've lost the difference between an interface and
>multiple inheritance.  This also doesn't handle the case where Vehicle
>and Idable are existing classes (from a library?) that you would rather
>reuse instead of re-writing.

If they are existing classes, then include them as members rather than as bases.



September 02, 2001
> Walter wrote:
>
> > If so then I've lost the difference between an interface and multiple inheritance.  This also doesn't handle the case where Vehicle and Idable are existing classes (from a library?) that you would rather reuse instead of re-writing.
> 
> If they are existing classes, then include them as members rather than as bases.

But if the existing class has *many* methods you want to use, the programmer will need to wrapper all of them:

class NewClass
{
   ExistingClass dummy;	// declare the member

   void foo(arg, ...) { return dummy.foo( arg ... ); }  // delegate

   // repeat for *all* the methods of ExistingClass
   ...
   ...
}

This approach is very tedious and error-prone.  That's the reason why Kiev introduce the 'forward' keyword:

class NewClass
{
   forward ExistingClass dummy; // newClass.foo(...) is automatically
				// forwarded to newClass.dummy.foo(...)
				// by the *compiler*
}


This solution is not perfect, but as long as there is no conflict it at least saves the programmers' labour, and it helps to reduce some possible programming errors.


BTW, Walter, have you decided to introduce any better approach into D other than Java's single inheritance + interface + "Copy&Paste" ?

YuQian

September 02, 2001
Yu Qian Zhou wrote in message ...
>BTW, Walter, have you decided to introduce any better approach into D other than Java's single inheritance + interface + "Copy&Paste" ?


No, I haven't. I understand that not having MI will result in some code duplication. I don't think, however, it is a cost that exceeds the greater understandability of non-MI code.


September 02, 2001
> Yu Qian Zhou wrote in message ...
>>BTW, Walter, have you decided to introduce any better approach into D other than Java's single inheritance + interface + "Copy&Paste" ?
> 
> 
> No, I haven't. I understand that not having MI will result in some code duplication. I don't think, however, it is a cost that exceeds the greater understandability of non-MI code.

I have to agree with Yu Qian, I've programmed some GUI's and java and sometimes you've objects which have implement several interfaces, but often only a single function of each. A good example are the 'Listeners' java has. A listener would be an event slot in qt language. You get all the GUI actions into there. Example were something like KeyboardListener, MouseListener, etc. Suprisingly the java API always provides each listener twice, once as an interface, and once as a normal class you can inherit. If the situation allows it you can inherit the Listener class and just overload the functions you want, but in some situations you alread inherit from something else. Then you've to implement the interface and write code for -every- function it provides. This is the code duplication how I think Yu Qian tried to express.

In my eyes somebody thought simple single inheritence was enough. Sounds like a good idea. But in pratice they soon discovered that there are cases it does not suffice, like in many cases one often seen example in java is 'Application' and 'Runable'. Okay you've to inherit for an Application to be start able. If you want to run another thread you've to implement the 'Runable' interface, because you can't overload also the 'Thread' class since you are already an application. In this dilemma the interfaces were introduced, a suitable workaround. But exactly in this example writing threaded code by inheriting 'Thread' is far more convient than implementing the 'Runable' interface which requires you to write more code, and to create an additional thread object as 'branch'.

I think single inheritence was an expiriment, worth taking altough. But looking at the results my impression is it failed. Why can't I just inherit both from 'Application' and from 'Thread' at the same time? I don't think MI is any bad if you implement it stronger typed than C++ did. A function is eitherway absolute unique identifyable or a compile error will be raised. The worst case that can happen is that the user has to specify from which parent he wants to call the function Foo() if both should have them.

Another aspect which make C++ inheritance complicated is public, protected and private inheritance. Something I never understood what the real benefits of it are. In the sense IS-A and HAS-A, I can hide what I have, but I should not be able to hide what I am.

Diamond inheritance? If it makes problems, just leave it away. You're still far more powerfull than single inheritence would provide.

- Axel