Weed wrote:
Don пишет:
That must mean that you inherit that class only to avoid duplicating
code. And that is easily done with template mixins.
It is possible that this polymorphism is not needed and should be
prohibited for operations by value. The class is ready, why it should
not be used and have to redo it?
Can not think about changing when the class is ready - he could have
enormous complexity and hierarchy.
This is the fundamental tradeoff at the heart of the matter.
In D, the choice of whether an object will use polymorphism or not is
considered a fundamental design decision.
This is awful! Much easier to give to the application programmer to
decide how it will use the derived class somewhere. Such a division
should be a basic principle of designing a complex program.
Even in C++, all of your base classes should be abstract.
Why?
See, for example,
http://www.artima.com/intv/modern.html
If you want to move between polymorphism and non-polymorphism in C++,
it's a non-trivial refactoring.
D gets significant benefits
from this.
Benefits:
1. Disappeared slicing
2. ?
That's not what I had in mind at all. I don't think slicing is such a
big deal in itself; it's just a symptom.
What do you mean?
Language complexity.
C++ allows you to defer the decision, but it doesn't come for
free.
Clarify what you mean?
(Generally speaking, statically typed languages do force you to make
more decisions at design time). Notice that you have little gotchas in
C++, such as the need to declare a virtual destructor on every struct
you think you might "someday" use polymorphically. It sticks around,
even if it never gets used.
One of the nice things about a D struct, compared to a C++ struct, is
that you *know* it's simple, it never has that kind of baggage.
D does choose different trade-offs from C++. If it was always the same,
it'd be the same language!
There is no need to compare the structs from C++ and D. In fact, in C++
classes and structures are the same.
Well, although the keywords are identical, there are two different
varieties of C++ objects muddied together: PODs, and polymorphic types.
You declare a type to be polymorphic by declaring a virtual function
inside it. In D, you do it with the 'class' keyword.
I like D's idea of POD structs + without them you can not ensure
compatibility with C, but it is very important.
Now we are talking about classes.
In C++ classes with the same problems, such as what they do not have a
common base class (Object in D). Passing classes by value is not a
problem - is an advantage.
Passing a polymorphic class by value rarely makes sense.
You can't get (runtime) polymorphism unless you go through a pointer.
Or reference (&). Thus, even polymorphic class on stack can be used
safely in C++.
Same thing. You're either not using value semantics, or not using
polymorphism. Not both at once.
As I said earlier, the presence of pointers is also an advantage,
although they are dangerous and can lead to complex bugs.
I don't think that is analagous. The issue is not primarily about with
the 'danger' of passing classes by value. It's about clear separation of
concepts.
BTW, if you're concerned about performance, you'd do well to use
compile-time polymorphism rather than run-time, when possible. D's
metaprogramming support leaves C++ for dead.
I think if there was a language with all the features as in D but with
the model objects from C++, he would have won great popularity. Mainly
it would have moved C++ developers who are satisfied with the model
classes of C++ but not satisfied with the absence of other modern
features: metaprogramming, contracts, delegates, closures etc.
I think D will get adequate popularity once it has a good library
situation. It only needs language changes inasfaras they are necessary
for library design.
What D better than Java or C#?
I'm wasting my time here. I'll not make any further comments on this
subject.
