>
>... but if you believe in allowing
> > fuller multiple inheritance to be used then what value
> is
> > there in having a language feature that duplicates what
> is
> > possible through using another language feature?>
> Is absolute minimalism the main driving force behind good
> language design? If that were the case, then why have
>
while,
do-while and
for, among other
> things?
Absolute minimalism
the main driving force? No.
Minimalisim
a driving force? I think it should be.
If an explicit "interface" feature had real advantages (bearing in mind that we already have MI), then maybe it should be added. What are those real advantages?
>
> The only possible advantage would be if the use of
> > multiple inheritance to do what Java interfaces do was
> so
> > convoluted as to be non-idiomatic. That simply isn't
> > true.>
> Doing interfaces in C++ via ABCs seems very clunky
> compared to the Java
interface. It is also more
> of a convention than a language construct; it is pretty
> easy to create almost-ABCs, either intentionally or
> accidentally.
Yes it's more of a convention than a language construct. What's wrong with that? I disagree that's it's clunky though.
I'd defend the ability to give an "interface" class a static member or static member function, or a convenience function defined in terms of the virtual functions:
class someInterface{
//it's inherent in our concept of what "someInterface"
//means that they can be compared and sorted.
//hence we provide for this:
virtual int cmp(const someInterface& rhs) = 0;
//these need not be virtual:
bool operator==(const someInterface& rhs)const
{
return cmp(rhs) == 0;
}
bool operator<(const someInterface& rhs)const
{
return cmp(rhs) < 0;
}
//all "someInterface"s can "process" an array of chars;
//This isn't far removed from the characters method
//on a SAX ContentHandler.
virtual void process(const char* start, const char* end) const = 0;
//often the user of someInterface has a string (indeed
//that would be safer. Also, we define process in terms
//of a sequence (first, last] but many people think of
//arrays as defined in terms of an initial pointer and a
//size (especially those who moved from C to C++:
void process(const char* start, size_t size) const{
process(start, start + size);
}
void process(const std::string& str) const{
process(str.data(), str.length());
}
/*other functions yadda yadda*/
};This isn't to say that you should always do this, and in my example the == and < operators seem a bit doubtful to me.
However if we wanted to overload process() in a similar manner using virtual functions then we force the simple implementation to be repeated in every class that implements this interface, we gain nothing except for more typing practice and a greater potential for bugs (it's also possible that we'll make things less efficient - my concern here wouldn't be so much efficiency as much as what some developers might do to try to avoid inefficiency).
>
> Arguably Java's interfaces have taught some C++
> > programmers about this way of using MI...>
> I don't really even think of the
interface in Java
> as being multiple inheritance. It seems more like a
> language construct for objects to
advertise what
> behaviors they support.
Inheritance advertises what behaviours a class supports! I think this is a much more important aspect of inheritance, particularly in design stages, than the fact that you can also inherit implementation (and hence program by difference).
>
> ...but then so has
> > COM (which is defined almost entirely in terms of
> > interfaces which is most naturally implemented in C++
> > using MI - though there are other ways, but then there
> are
> > always "other ways").>
> COM is even clunkier than pure C++! The salient point
> is that the
interface in Java is a very clean and
> simple thing. Yes, COM is built up around interfaces,
> but COM itself is such a huge complicated, crufty mess,
> that it is nearly impossible to see the proverbial
> forest.
Of course COM is clunkier than pure C++, it was an API designed to share objects between a variety of languages - including some with no concept of OO at all - on a variety of operating systems. That's an inherently clunky problem.
>
> Even so a language feature shouldn't exist to teach
> you
> > how to use another language feature.>
>
> Why not?!? What's wrong with language features that
> help you learn how to be a better programmer? A language
> feature that does this will probably be more effective at
> improving programmers than any number of books, articles,
> mentors or courses.
Oh, every language feature should teach you how to be a better programmer - it should encourage good programming and discourage bad programming (I love how awkward the new C++ casts are, a little rap across the knuckles every time you cast something). But it should also stand on it's own, otherwise it stops being a good way to learn and becomes "another thing to learn".
In Java Interface both teaches the technique and stands on it's own. If added to C++ it would only do the former.
Looking at it another way, do we need a language feature for everything a programmer should learn?
> The presence of the
interface keyword in Java has
> taught more programmers this concept than anything else,
> probably. While it is
possible to create and use
> interfaces in C++, it is also possible to program in C++
> for many years without ever being keenly aware of the
> interface concept.
It's possible to program in C++ without being keenly aware of the class concept (every example of C in K&R is valid C++).
This cuts both ways, C++ adapts to new paradigms well (I think C++ deserves a lot of credit from the way OO has progressed from the earlier definitions - as mentioned by Dave above) and this is partly because it doesn't force much upon the user, but as well as working well with good paradigms and design strategies it will give results to people using dain bramaged paradigms and poor design strategies (not great results, but good enough results that the programmer may continue with a poor methodology for longer than otherwise).
This isn't a feature that is a requirement of a language, but I'm glad there is a major language that has it to such a large extent.