• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Archived

This topic is now archived and is closed to further replies.

zacharya

Java and single inheritance

252 posts in this topic

I just want to know why Java doesn''t support multiple inheritance.... Everybody told me that Java''s OOP concept is better than C++ but what makes me curious is why in Java I can''t do multiple inheritance like in C++.
0

Share this post


Link to post
Share on other sites
quote:
Original post by zacharya
Everybody told me that Java''s OOP concept is better than C++ but what makes me curious is why in Java I can''t do multiple inheritance like in C++.
Choice by the language designers. Specifically, a reaction to a common problem in C++.

In C++, multiple inheritance can often lead to the "diamond inheritance" problem - where a class derived from two classes with a common ancestor consequently receives two (or more) copies of the ancestral class. This is solved with virtual inheritance, but the Java language designers thought it better to attempt to idiot-proof the language by disallowing MI and substituting multiple implementation of interfaces (which can have no data members) instead.

P.S. This lack of respect for my intelligence - repeated often in Java - is one of the reasons I dislike it. Caveat emptor.
0

Share this post


Link to post
Share on other sites
quote:
Original post by Arild Fines
Because it''s very hard to implement, and almost impossible to implement correctly(just look at what a mess it is in C++. People say Eiffel got it right, though).
I''d like to know your opinions on MI in Python. I find the order of inclusion method interesting, though I''ll readily admit that something about Python makes inheritance less of a critical method - probably the fact that its dynamic typing system and introspective qualities allow for fairly generic programming.
0

Share this post


Link to post
Share on other sites
quote:
Because it''s very hard to implement, and almost impossible to implement correctly(just look at what a mess it is in C++. People say Eiffel got it right, though).

Eiffelists say that. It''s not clear that they''re right, however. MI does raise certain issues, but it''s probably worth having in spite of these issues.
0

Share this post


Link to post
Share on other sites
quote:
Original post by DrPizza
quote:
Because it''s very hard to implement, and almost impossible to implement correctly(just look at what a mess it is in C++. People say Eiffel got it right, though).

Eiffelists say that. It''s not clear that they''re right, however. MI does raise certain issues, but it''s probably worth having in spite of these issues.



Yes, it''s worth having because then I have the choice to use it if I want to. Just like operator overloading, pointers, etc. When in the right hands, they are useful tools. When in the wrong hands, they can be dangerous, but those hands are what languages like Java were invented for.



--
Dave Mikesell Software
0

Share this post


Link to post
Share on other sites
I''ve never understood the problem people have with multiple inheritance. It is one of the most powerful features in C++ and I don''t think I could program without it. Maybe some little fluffy flowery programs, but I try to avoid those kinds of projects. Sure, you have to keep up with your virtual inheritances, but it isn''t that hard a concept to use. I think people make it harder than it needs to be, cuz it isn''t that hard and can allow you some EXTREMELY powerful code.
0

Share this post


Link to post
Share on other sites
quote:
Original post by Oluseyi
P.S. This lack of respect for my intelligence - repeated often in Java - is one of the reasons I dislike it. Caveat emptor.


That's an interesting viewpoint. I find it to be a useful separation of interface and implementation. Consider the difference between an interface and an abstract class in Java. In C++, they are one and the same - we create them using pure virtual methods. However, often C++ interfaces have concrete methods implemented. This, IMO, can be a poor design decision in some cases and is often done by those who don't understand the difference. I don't consider Java's version an insult to anyone's intelligence any more than a sophisticated IDE is (when compared to command line development). It was a design decision to aid in reducing common mistakes.

Personally, the only need I have ever for multiple inheritance in C++ is to implement interface-like functionality. I'm sure others may have had a need for inheriting multiple concrete objects, but I have yet to run into such a case myself. At least, not since I learned to think in terms of interfaces. I think there are many cases when people think they need to inherit multiple concrete objects when they really don't.

[edited by - aldacron on February 16, 2004 9:12:33 PM]
0

Share this post


Link to post
Share on other sites
quote:
Original post by Aldacron
That''s an interesting viewpoint. I find it to be a useful separation of interface and implementation. Consider the difference between an interface and an abstract class in Java. In C++, they are one and the same - we create them using pure virtual methods. However, often C++ interfaces have concrete methods implemented. This, IMO, can be a poor design decision in some cases and is often done by those who don''t understand the difference. I don''t consider Java''s version an insult to anyone''s intelligence any more than a sophisticated IDE is (when compared to command line development). It was a design decision to aid in reducing common mistakes.
An IDE still allows you to drop to command line; the option remains, allowing you to make the choice. IDEs extend the command line, as opposed to hiding it. The analogy is tenuous.

quote:
Personally, the only need I have ever for multiple inheritance in C++ is to implement interface-like functionality. I''m sure others may have had a need for inheriting multiple concrete objects, but I have yet to run into such a case myself (emphasis added).
I need say no more.

By the way, I dislike C++ about half as much as I dislike Java.
0

Share this post


Link to post
Share on other sites
quote:
Original post by Oluseyi
Choice by the language designers. Specifically, a reaction to a common problem in C++.

That''s the brochureware rationalisation, but there''s also the conspiracy theory that it was a choice by the marketing department, who would have been fully aware having a product to market is more lucrative than waiting for the engineers to realise an MI approach which isn''t so `broken''. It might have helped if they hadn''t based their object model on one perceived to be broken...
0

Share this post


Link to post
Share on other sites
quote:
Original post by Aldacron
Personally, the only need I have ever for multiple inheritance in C++ is to implement interface-like functionality.

How about this one: without MI of implementation, contractual assertions on interfaces have to be specified in each and every concrete subclass, rather than just once in the interface itself.
0

Share this post


Link to post
Share on other sites
quote:
Original post by Aldacron
Personally, the only need I have ever for multiple inheritance in C++ is to implement interface-like functionality. I''m sure others may have had a need for inheriting multiple concrete objects, but I have yet to run into such a case myself. At least, not since I learned to think in terms of interfaces. I think there are many cases when people think they need to inherit multiple concrete objects when they really don''t.



This same tired "argument" comes equally often from the C#
"fans".

Just because you didn''t find any use, it doesn''t mean other
people haven''t.

The option to use implementation-inheritance should have
been up to the programmer, not the language designer.



Kami no Itte ga ore ni zettai naru!
0

Share this post


Link to post
Share on other sites
I agree with the point about the only ''real use'' for multiple inheritance is with multiple interface inheritance not implementation.

Sure you can come up with examples of multiple implementation inheritance, but almost invariably they make for really horrible code. And equally invariably they can be written much cleaner and simpler via an interface viewpoint.

Oh and the arguement about C++ multiple implementation inheritance being ''great because I can use it if I want it'', is bogus on two counts. One already described, but the other is that it cripples the language when you do want to do interface style programming.

For example...

struct IBlah
{
virtual void A()=0;
};

struct IBlah2ublic IBlah
{
virtual void B()=0;
};

class CAbstractBlobublic IBlah
{
....
void A() { /* Do something */ }
}

class CBlobublic CAbstractBlob,public IBlah2
{
...
}

CBlob is great isn''t it? As I have to tell C++ I want IBlah2''s A to call CAbstractBlobs implementation. Jeez...

You might think thats a crap example - but it really isn''t. If you have done any COM programming then you hit this kind of thing all the time.

So in a nut shell I believe Java + C# single inhertiance architecture is absolutely the way to go. It loses no flexibility (you can still implement everything you can with C++ multiple inheritance - as you have multiple interface inheritance) whilst simplifying the whole notion of an objects. On top of that it removes the madness described above.

Sign me up.
0

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
I agree with the point about the only ''real use'' for multiple inheritance is with multiple interface inheritance not implementation.

I''ve already presented an effective counter-example to this assertion.
quote:

Sure you can come up with examples of multiple implementation inheritance, but almost invariably they make for really horrible code. And equally invariably they can be written much cleaner and simpler via an interface viewpoint.

That does not hold for the scenario I described.
quote:

Oh and the arguement about C++ multiple implementation inheritance being ''great because I can use it if I want it'', is bogus on two counts. One already described, but the other is that it cripples the language when you do want to do interface style programming.

No it doesn''t. What cripples the language is the conflation of packaging mechanism and class construct. This problem still exists in Java, only mitigated by the lack of MI of implementation. This approach does not address the problem, merely ignores it in order to achieve ease of implementation (of the Java platform).
quote:

So in a nut shell I believe Java + C# single inhertiance architecture is absolutely the way to go.

And I believe the way to go is to not derive new languages using something badly designed as the baseline. Java does not attempt to answer any interesting problems of CS, it exists to make money for its stakeholders. I take the removal of multiple implementation inheritance to be evidence in support of that assertion. Given that Guy Steele was involved early on in the Java project, I find it hard to believe there was no awareness of possible solutions to the MI problem.
0

Share this post


Link to post
Share on other sites
I can''t think of a time I''ve ever wanted multiple inheritance.

Hell, I don''t even want *single* inheritance all that often, and tend not to build deep hierarchies. I tend to do more with delegation (are there any languages out there that facilitate delegation of multiple methods, say by doing simple delegation to aggregates by default?).

If you really feel you need proper MI, then use a language which supports it. And STFU.
0

Share this post


Link to post
Share on other sites
If you dissallow people to do certain things you have to provide a better alternative.

Nameclashes can easily be resolved through renaming as in Eiffel. Implementation inheritance has a special construct in Eiffel, expanded (non-conforming) inheritance.

Seperating interface and implementation is a double edged sword. If there is a reasonable default implementation you end up with redundant code in every class implementing the interface.

Back to learning lisp...
0

Share this post


Link to post
Share on other sites
quote:
Original post by Stonicus
Sure, you have to keep up with your virtual inheritances, but it isn''t that hard a concept to use.



I''m sure you can. But what about the poor soul who has to maintain your code?
0

Share this post


Link to post
Share on other sites
C++ was designed to be a multi-purpose language used for a variety of problem domains. There may not be many valid uses for MI, but for the problems where it is the best solution it''s invaluable. Same with operator overloading, templates, pointers, etc.

The problem I have with Java is that they take away all of these things and yet the advocates still try to claim that it''s a multi-purpose language. It''s not. It''s a language for client server web applications.

--
Dave Mikesell Software
0

Share this post


Link to post
Share on other sites
quote:
Original post by tangentz
quote:
Original post by Aldacron
Personally, the only need I have ever for multiple inheritance in C++ is to implement interface-like functionality. I''m sure others may have had a need for inheriting multiple concrete objects, but I have yet to run into such a case myself. At least, not since I learned to think in terms of interfaces. I think there are many cases when people think they need to inherit multiple concrete objects when they really don''t.



This same tired "argument" comes equally often from the C#
"fans".

Just because you didn''t find any use, it doesn''t mean other
people haven''t.



I wasn''t arguing anything. Nor was I saying other people haven''t had a use for it. Notice the part that reads "I''m sure other people may have...". I was really only looking for a specific example from Oluseyi on when MI is really needed.

quote:

The option to use implementation-inheritance should have
been up to the programmer, not the language designer.



I do have an issue with this oft repeated mantra, though. Language designers are free to design their language in anyway they see fit. The important thing is that we, as programmers, have choices. We can pick the language best suited for the job. There''s no such thing as a one-size-fits-all language. Each project has its own requirements for performance, portability, time to market, extensibility, yadda, yadda. Then there are other factors such as the experience of the team and available funds. All of this should play a role in which language to use for a particular project. Blindly choosing one over the other for every project will often lead to a failure to meet one or more of the project requirements.
0

Share this post


Link to post
Share on other sites
quote:
Original post by Aldacron
Language designers are free to design their language in anyway they see fit.



Sure, they can. Sometimes they end up with something like BF.

quote:

The important thing is that we, as programmers, have choices. We can pick the language best suited for the job.



If only this were true. The real world doesn''t work that
way. The company or the "technical director" chooses a
language and the "lowly grunt" programmers have to use
that language. The choice has already been made by someone
else.

But, anyway, you failed to provide any reason as to why
the option to use implementation-inheritance should
not be up to the programmer.

All you said was that programmers have the choice to use
the "best language for the project" (so they can choose to use
something other than Java/C#), but they very often don''t.




Kami no Itte ga ore ni zettai naru!
0

Share this post


Link to post
Share on other sites
quote:
Original post by tangentz
quote:

The important thing is that we, as programmers, have choices. We can pick the language best suited for the job.



If only this were true. The real world doesn't work that
way. The company or the "technical director" chooses a
language and the "lowly grunt" programmers have to use
that language. The choice has already been made by someone
else.



Okay, semantics. Replace the word 'programmers' with 'technical directors' or 'project managers' or any title of your choosing. All the more reason why the 'lowly grunts' need to diversify their skill set. The more languages you have on your plate the more job opportunities open up and, perhaps, the more valuable you become to the team.

quote:

But, anyway, you failed to provide any reason as to why
the option to use implementation-inheritance should
not be up to the programmer.



We're on different wavelengths. There's absolutely no reason why it should not be up to the programmer. But neither is there a reason why it should . That's why I said we (or our tech directors) have the freedom to choose the right tool for the job.

quote:

I just want to know why Java doesn't support multiple inheritance....

Everybody told me that Java's OOP concept is better than C++ but what makes me curious is why in Java I can't do multiple inheritance like in C++.



Never listen to anyone who says one language is better than another. It's nearly always objective (based upon a person's personal experience and preferences), and the only way to see for yourself is to try it. And the short answer to your question is: multiple inheritance did not fit in with Java's design goals, whereas the interface mechanism is much simpler and can solve most problems where multiple implementation-inheritance is used (sometimes in conjunction with abstract classes).

What people often forget is that Java was developed with very specific design goals that were quite different from C++. One of Stroustrup's major goals with C++ was to make it flexible enough to allow programmers to use what they need, but not force it on them when they don't (virtual functions are a great example of this, as you must declare them explicitly to make use of them). While some live for this, others find the resulting language a complex beast that is difficult to master.

One of the major goals of Java, OTOH, was to keep the language simple, object oriented, and familiar. In line with the goal of keeping it simple, some of the features in C++ considered to be problematic and/or complex were left out, and some features which were considered too restrictive by the C++ designers were added. This is, understandably, why many experienced C++ programmers disdain Java - they have gotten into a comfort zone with C++ where avoiding any side effects of the language features is second nature. To them, using Java is like mom holding their hands.

The Java Language Envionment white paper explains the reasoning behind the design decisions Gosling and team made, including the lack of multiple inheritance. But to get more details on the problems with multiple inheritance (which the white paper doesn't go into) you'll have to google a bit. Bill Venners wrote an article
which goes into it somewhat. It's interesting to note that Java's interface mechanism was based upon Objective-C (which some claim is a much better language than either C++ or Java).



[edited by - aldacron on February 17, 2004 11:41:56 PM]
0

Share this post


Link to post
Share on other sites
quote:
Original post by dmikesell
C++ was designed to be a multi-purpose language used for a variety of problem domains. There may not be many valid uses for MI, but for the problems where it is the best solution it''s invaluable.

Generally, I agree with this. The issue is that, when the implementation of MI (and inheritance in general) is flawed, it is convenient to believe that there aren''t any good uses for it. If you have an MI mechanism that works well, then you are likely to find more use for it. When you don''t have MI at all, its even more convenient to rationalise the absence through claims that there aren''t any uses for it! Once on this slippery slope, we''re not too far from stupid Turing equivalency arguments.
quote:

The problem I have with Java is that they take away all of these things and yet the advocates still try to claim that it''s a multi-purpose language. It''s not. It''s a language for client server web applications.

No its not. Its a language for marketing.
0

Share this post


Link to post
Share on other sites
quote:
And I believe the way to go is to not derive new languages using something badly designed as the baseline. Java does not attempt to answer any interesting problems of CS, it exists to make money for its stakeholders.

Whatever things Java was designed for, making money doesn''t appear to be one of them. Sun remains predominantly a hardware company; Java attempts to commoditize hardware. This is a stupid move for any hardware company. It can only be understood when one considers Sun''s pathological hatred for MS (Windows being another product that commoditizes hardware). In this context, providing a platform such as Java makes sense -- it''s an attack on the Windows platform.

Still not good for a money-making perspective, of course, but it makes that scrotum McNealy happy.

quote:
No its not. Its a language for marketing.

"it''s".
0

Share this post


Link to post
Share on other sites
quote:
The Java Language Envionment white paper explains the reasoning behind the design decisions Gosling and team made, including the lack of multiple inheritance. But to get more details on the problems with multiple inheritance (which the white paper doesn''t go into) you''ll have to google a bit. Bill Venners wrote an article
which goes into it somewhat. It''s interesting to note that Java''s interface mechanism was based upon Objective-C (which some claim is a much better language than either C++ or Java).

What a load of old bollocks.

a) The diamond "problem" is not as big a problem as people make out.
b) Implementation inheritance (as provided in C++, at least) permits interface inheritance; C++ allows one to use "interfaces" in just the same way as Java does, if one chooses.
0

Share this post


Link to post
Share on other sites