Isn't D too inconsitent? I'm used to use templates to generate code for
everything the fullfills certain criterias. Normaly I can think of these
criterias on my own, e.g. the object has to be asignable. In D you can't do
that. A lot of behavior is predefined in the language but has different meanings
in different situation. In template-code you can never know, what actualy is
happening. Things are magicaly allowed but don't do any usefull thing. You find
a lot of behavior like that in D.
On very simple examples it's obvious but with more complex structures you soon
will get totaly confused.

Eigther the language has to change a lot to be much more conistent or you should
ban templates.
You already baned multiple inheritance. I never understood people that find MI
complex or hard to understand. But template code in D is complicated.

Matthias Becker wrote:

> Isn't D too inconsitent? I'm used to use templates to generate code for
> everything the fullfills certain criterias. Normaly I can think of these
> criterias on my own, e.g. the object has to be asignable. In D you can't
> do that. A lot of behavior is predefined in the language but has different
> meanings in different situation. In template-code you can never know, what
> actualy is happening. Things are magicaly allowed but don't do any usefull
> thing. You find a lot of behavior like that in D.
> On very simple examples it's obvious but with more complex structures you
> soon will get totaly confused.
> 
> Eigther the language has to change a lot to be much more conistent or you
> should ban templates.
> You already baned multiple inheritance. I never understood people that
> find MI complex or hard to understand. But template code in D is
> complicated.

Do you have some examples in mind?
In general one problem with writing generic code for different types is that
different types have different semantics (eg - structs vs classes) so it is
natural that the template code has to be careful. One nice thing about
Java/C# generics is that the template can specify a restriction in the
template parameter list, which gives the template writer a consistent way
of expressing requirements.

Matthias Becker wrote:
> Isn't D too inconsitent? I'm used to use templates to generate code for
> everything the fullfills certain criterias. Normaly I can think of these
> criterias on my own, e.g. the object has to be asignable. In D you can't do
> that. A lot of behavior is predefined in the language but has different meanings
> in different situation. In template-code you can never know, what actualy is
> happening. Things are magicaly allowed but don't do any usefull thing. You find
> a lot of behavior like that in D.
> On very simple examples it's obvious but with more complex structures you soon
> will get totaly confused.

In order for the language to become more consistent, you need to address
the inconsistencies one at a time.  It might truly be an inconsistency
or it might be a misunderstanding.  To simply say there are
inconsistencies isn't enough to get them fixed.  After all, Walter may
fix a dozen inconsistencies, but if it isn't the one you are concerned
about then you will still claim that none of the inconsistencies are
fixed.

Just enumerate them one at a time with examples of why they are
inconsistent, and how you expected them to behave.

> 
> Eigther the language has to change a lot to be much more conistent or you should
> ban templates.
> You already baned multiple inheritance. I never understood people that find MI
> complex or hard to understand. But template code in D is complicated.

RE MI:

The major problem with MI was not it being hard to understand, but when
you have a "diamond" problem, which destructor is called in what order.
The "diamond" problem is where you are doing MI and two or more of your
superclasses have the same base class.  This is a documented problem in
C++.  Now if these classes are nothing but pure virtual base classes
(AKA interfaces) there is no problem to begin with.  So that is the path
that is taken in most modern languages now.

"Matthias Becker" <Matthias_member@pathlink.com> wrote in message news:cf7l18$hlu$1@digitaldaemon.com...
> Isn't D too inconsitent? I'm used to use templates to generate code for everything the fullfills certain criterias. Normaly I can think of these criterias on my own, e.g. the object has to be asignable. In D you can't
do
> that. A lot of behavior is predefined in the language but has different
meanings
> in different situation. In template-code you can never know, what actualy
is
> happening. Things are magicaly allowed but don't do any usefull thing. You
find
> a lot of behavior like that in D.
> On very simple examples it's obvious but with more complex structures you
soon
> will get totaly confused.

I'm guessing that most of the problem you're experiencing comes from trying to handle both structs and classes with the same generic code. But structs, being value types, and classes, being reference types, behave in fundamentally different ways. Trying to have the same generic template handle both is probably going to have problems. It's probably best to do a specialization for class types:

    template foo(T : Object) { ... } // for reference semantics
    template foo(T) { ... } // for value semantics

>The major problem with MI was not it being hard to understand, but when you have a "diamond" problem, which destructor is called in what order. The "diamond" problem is where you are doing MI and two or more of your superclasses have the same base class.  This is a documented problem in C++.  Now if these classes are nothing but pure virtual base classes (AKA interfaces) there is no problem to begin with.  So that is the path that is taken in most modern languages now.

a) How often do diamond structures occure in realty
b) Eiffel doesn't have problems with diamond structures. In C++ you can avoid
problems with virtual base classes, but than you have to know about the whole
inheritece structer

Matthias Becker wrote:

>>The major problem with MI was not it being hard to understand, but when
>>you have a "diamond" problem, which destructor is called in what order.
>>The "diamond" problem is where you are doing MI and two or more of your
>>superclasses have the same base class.  This is a documented problem in
>>C++.  Now if these classes are nothing but pure virtual base classes
>>(AKA interfaces) there is no problem to begin with.  So that is the path
>>that is taken in most modern languages now.
> 
> 
> a) How often do diamond structures occure in realty
> b) Eiffel doesn't have problems with diamond structures. In C++ you can avoid
> problems with virtual base classes, but than you have to know about the whole
> inheritece structer

The original C++ io system is based on the diamond structure, and the
virtual destructors is the work around for it.  The other name for it is
Fragile Base Class problem.  Anyway, Eiffel has language protection from
these things, though I am not sure what they are.

In article <cf8i4v$tkb$2@digitaldaemon.com>, Berin Loritsch says...
>
>The original C++ io system is based on the diamond structure, and the virtual destructors is the work around for it.

Yup.  My stream rewrite follows a similar design to the C++ version and it took some doing to overcome the lack of MI.  But the fact that it can be overcome implies that MI is not necessary in D, which I consider a good thing.


Sean