Quote:Original post by Telastyn

Quote:Original post by Programmer16

Quote:Original post by RDragon1
and get rid of that silly C prefix. Csoldier is a lot less readable than Soldier.

You really should try to be helpful with your replies. If somebody likes prefixing their class names with 'C' then who are you to say they shouldn't?

Someone who would be more helpful if they didn't have to spend more time and effort ignoring useless prefixing.

My point is that it's a preference and it's rude to push yours onto other people. It takes no more time than if you have a namespace tacked on there.

Also, it's not entirely useless. It does help keep names open for use as variable names (Texture, Vector, Point, Device, etc.)

Btw, do you think he really would have been more helpful seeing as he wasted oh so much time and effort getting by that one little letter yet he still didn't post anything helpful?

An even better question is why was his coding preferences called into question when they had nothing to do with his problem?

[Edited by - Programmer16 on April 21, 2007 1:09:57 AM]

Quote:Original post by Mikle3
1. Let's consider multiple race (for instance) - If I got a few races, say elf, human and gnome. Say we still have the Race class, what's better - Inherit those 3 from race and use Race (With maybe some "race specific" code abstracted using some kind of a callback) or create the Modification of race and use them as attributes?

There's surprisingly little difference; as long as the race never changes and you don't do RTTI, there's actually no outward difference. Again, though, prefer composition to inheritance. If only some numbers are different, then inheritance isn't even worth considering. If there's actually code which is different, then use a Strategy pattern if possible. Basically, you want to make the classes which do the actual inheritance as teeny as possible.

Quote:2. How about using introspection (Like python's) for making such stuff? Something like dir()-ing the class to get its special powers? Will this be as fast? Becuase it will allow a bit more maneuvering power, and extensibility.

That's a trickier question. I wouldn't use introspection like that, but it might be reasonable to have a Race consist of a series of Modifier objects which modify the attributes of the character and/or add special powers. This is something where the Right Way is much less clear.

Quote:3. If someone has the will to elaborate - Why is multiple inheritance isn't as good a solution?

Because it's not the right way to think about it. If there's an elf mage, you think about him as a guy who is an elf and who also is a mage. The fact of his elfhood and the fact of his magehood are not inextricably linked. In your code, this would manifest itself as an explosion of classes; you'd have to have a class for every potential race/character class combination, and you'd need some ugly factory stuff to actually pick one.

Sneftel: regarding multiple inheritance, what if you could do it like this:

Character* tom_the_elf_wizard = new Elf&&Wizard

the && operator would create an anonymous class at compile time. Do you think that it would be good? Assume that all inheritance is automatically virtual so that there is no dreaded diamond problem.

Quote:Original post by Mikle3
2. How about using introspection (Like python's) for making such stuff? Something like dir()-ing the class to get its special powers? Will this be as fast? Becuase it will allow a bit more maneuvering power, and extensibility.

I don't think introspection really helps here, at least not in python. You could more easily use a dict to hold the special powers.

Quote:Original post by Glak
Sneftel: regarding multiple inheritance, what if you could do it like this:

Character* tom_the_elf_wizard = new Elf&&Wizard

If you have a character creation screen where the player selects race and class then you'll need explicit code for every combination. If you use composition instead of multiple inheritance, then you only need code for each race and each class, instead of every combination. For your syntax to really be an improvement, you'd also need to have run-time class creation (which is possible in some languages), but the resulting system would still be more complicated.

Quote:Original post by Glak
Sneftel: regarding multiple inheritance, what if you could do it like this:

Character* tom_the_elf_wizard = new Elf&&Wizard

the && operator would create an anonymous class at compile time. Do you think that it would be good? Assume that all inheritance is automatically virtual so that there is no dreaded diamond problem.

If that sufficed for your design, it would be proof positive that multiple inheritance was gaining you absolutely nothing, because there's nothing about ElfWizard that doesn't directly come from either Elf or Wizard. The bottom class would have an empty class body.