Charles Hixson wrote:
> 
> Dan Hursh wrote:
> > ...  It's a little concerning how often folks here take the
> > opinion that "Feature X has problems and I never use it anyway,
> > so no body else 'really' needs it."  I'm not specificly blaming
> > you, but i've lost track of how many time if seen that reasoning
> > tonight.  I'm afraid I'll see it a lot in the 275 I still have
> >  to read.
> >
> > Dan
> >
> The problem is, there's a limited amount of developer time/energy.  So one must remember K.I.S.S.  OTOH, the basic features need to be present that will allow the language to grow over time into the "proper" shape.
> 
> Were I arguing for what I want, I'd not only argue for multiple inheritance, but for an interpreter as well as a compiler, with linkages between the object code from the compiler and the code executing in the interpreter.  That way features that couldn't be totally compiled would be able to have their flexible features managed by the interpreter, while the rest could run at compiled speed.  And code that was simple enough could be unzipped from the interpreter, and run stand-alone.
> 
> But let's be reasonable.  Interfaces + delegation can handle almost all of what multiple inheritance can handle.  If there are ways to expose the C compatible links, then Python or Ruby can be used for the interpretive layer.  etc.  If it gets too complex, it won't get done.
> 
> People argue for what they want, and Walter *decides*.  It MUST be that way.


	True.  I got whiny.  It was past my bed time.  I can agree with
K.I.S.S. and growing the language.  I am afraid of having a library
based on the state of the language before it grew.  Libraries are
sometimes harder to change than languages once they are in use.  Of
course it will probably be a while until we have a library that sticks.
	OTOH, I don't buy the "I don't like it ..." argument.  Walter is about
the only one who can get away with that and from what I can tell that's
not his style.  I just don't want to give up on finding a good
implementation of a good functionality just because someone else doesn't
use or like a bad implementation of it.  I'm still too young and
idealistic for that.

Dan Hursh wrote in message <3B875392.F1956643@infonet.isl.net>...
> I guess I'm also a little scared that a debate will end with "I don't
>use it ...".  I doubt you would end a debate that way and I owe you an apology for acting like you might.

Unfortunately, the reality is I can't implement a lot of great features. There are just too many.

> Along with what you said, C++ is too big.  I hope D does not ever
>become like C++ in that sense.  I like to see all the interest here, but in the end I would rather that D, in it entirety, be something that "feels right" inside one person's head (yours on this case) than to have it be the language that made it though a committee with the least amount of bickering.

I think it feeling right is important.

> I guess I'll hope D is a good incremental language.  And I've also
>convinced myself that the library can be a very huge source of evil if it forces the user to understand all of it before he can use any of it. (perhaps the library should be a bunch of small, independent, compatible pieces?)

Yes, I want to make the library that way. The Java library turns out to be if you use any piece of it, you drag in the whole thing.

When everything inherits from a common Object class, the argument for templates does grow weaker.  C++ needs templates because there is no common ancestor.

But when you write generic functions for arguments of class Object, you have explicitly overridden type safety.

The original motivation behind templates was to provide a type-safe means of replacing macros.  A template captures the concept of operations on classes returning functions and other classes.  Templates, though, appear klugey because they use a different syntax than normal functions and methods to achieve their aims.

Likewise, when everything inherits from a common class, multiple inheritance appears to be not so necessary.  Java tried to eliminate multiple inheritance with interfaces -- but interfaces are nothing more than multiple inheritance with abstract classes. (It looks like a horse, whinnies like a horse, and smells like a horse...)

I'll mention my suggestion about multiple inheritance:

Implement, but make all inheritance virtual -- eliminate the virtual keyword.

"Glen Dayton" <dayton@timesten.com> wrote in message news:9mh7ah$1s7a$1@digitaldaemon.com...
> Likewise, when everything inherits from a common class, multiple
inheritance
> appears to be not so necessary.  Java tried to eliminate multiple inheritance with interfaces -- but interfaces are nothing more than
multiple
> inheritance with abstract classes. (It looks like a horse, whinnies like a horse, and smells like a horse...)

The Java interface definition is more of a 'contact', something that the class has to implement. This is one of the best features Java ever implemented -- you could simulate this with an abstract class either directly inherited from, or then with multiple inheritance in C++, but opening up full multiple inheritance is not really needed. The few cases I've seen this tried out in production platforms, such as Pink's mixin classes, it was mostly to support 'contracts' or otherwise provide mixins for building far too complex code. I rather see a nice interface definition than MI, as MI will just cause all kinds of strange pains, namespace issues, which of the named member functions or fields should override, and other similar nastiness.

--Kent

Glen Dayton wrote:
> 
> When everything inherits from a common Object class, the argument for templates does grow weaker.  C++ needs templates because there is no common ancestor.

	There are costs for this.  To get template functionality from a base
class, you have to use virtual functions (a performance hit) and you
have to deal with type error at runtime when template work them out at
compile time.

> But when you write generic functions for arguments of class Object, you have explicitly overridden type safety.

	But with templates too, you still have to ability to choose type
safety.

> The original motivation behind templates was to provide a type-safe means of replacing macros.  A template captures the concept of operations on classes returning functions and other classes.

...at compile time, like macros.

> Templates, though, appear klugey
> because they use a different syntax than normal functions and methods to
> achieve their aims.

  Not to me.  Template appear kludgy because the syntax for them is
ambiguous and has to be backward compatible with C.  I don't know if
that got compatibility, but it is definitely backward.

> Likewise, when everything inherits from a common class, multiple inheritance appears to be not so necessary.  Java tried to eliminate multiple inheritance with interfaces -- but interfaces are nothing more than multiple inheritance with abstract classes. (It looks like a horse, whinnies like a horse, and smells like a horse...)

	There are cases of code reuse that single inheritance (even with
interfaces) do not handle well.  You can say they handle those cases the
same way you can say C handles type based dynamic dispatch.  You can
kludge it in, but you feel dirty in the morning.

> I'll mention my suggestion about multiple inheritance:
> 
> Implement, but make all inheritance virtual -- eliminate the virtual keyword.


Dan