www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Are Templates usefull in D?

reply Matthias Becker <Matthias_member pathlink.com> writes:
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.
Aug 09 2004
next sibling parent Ben Hinkle <bhinkle4 juno.com> writes:
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.
Aug 09 2004
prev sibling next sibling parent reply Berin Loritsch <bloritsch d-haven.org> writes:
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.
Aug 09 2004
parent reply Matthias Becker <Matthias_member pathlink.com> writes:
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
Aug 09 2004
parent reply Berin Loritsch <bloritsch d-haven.org> writes:
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.
Aug 09 2004
parent Sean Kelly <sean f4.ca> writes:
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
Aug 09 2004
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"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

 that. A lot of behavior is predefined in the language but has different

 in different situation. In template-code you can never know, what actualy

 happening. Things are magicaly allowed but don't do any usefull thing. You

 a lot of behavior like that in D.
 On very simple examples it's obvious but with more complex structures you

 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
Aug 09 2004