Inheritance vs Composition...

[hub]

... or how to properly extend Irrlicht functionality.
I've been considering this issue in regard to writing a game engine on top of existing Irrlicht hierarchy. I would like to derive some IGameNode (for insance) out of ISceneNode (or IAnimatedMeshSceneNode or whatever). Since these are just interfaces it's necessary to create a non-abstract class like CGameNode, which would have to inherit from CSceneNode. And here is the problem - all CScene* classes are Irrlicht intenal classes and don't seem to have been exported into the irrlicht.lib. In the result I get undefined reference errors during linking. The only choice (hopefully not)
is to simply add mentioned classes into irrlicht project. Well, I mean into my irrlicht engine project file (in VS for instance), not Nico's:)
But this means tampering with the engine itself and doesn't look promising, not to mention constant rebuilding of the whole (pretty big) project (well, not as much of a problem in VS.)
The composition concept seems far easier in implementation at first, but the impression soon turns out to be deceiving, since you can no longer benefit from polymorphism, or even brute downcasting. It's especially tiresome in functions like getSceneNodeFromRayBB (or something), which make it pretty hard (or at least ugly) to identify the 'game entity' connected with the scene node.
I'm curious to see how you approached this problem! I hope I'm not the only one to encounter it

[uzik]

I haven't run into this so far, but I expected I would at some point.

I usually chose based on non technical considerations.

If the library is likely to be modified, and if I'm going to be trying to
integrate those changes into my project later, then it's easiest
not to change the library code. Then I'd just define a new class derived
from the existing ones and add the functionality I need. This doesn't
always work, sometimes stuff I need access to is declared as
private or protected. It's easy to change the declarations and the
library usually compiles afterward. Later you can make those
same changes to a new version without major rework.

If the library is static (development wise), or purchased without free
updates, then I might extend the library.