Wim, Thanks for chiming in on the discussion!
>* Allowing run-time typing (RTTI) > >I would allow it, but be very careful not to depend havily on it. >What I see often, is the following construct: > > if(dynamic_cast<X*>(a) != NULL) > do X specific function calls on a > else if(dynamic_cast<Y*>(a) != NULL) > do Y specific function calls on a > >This should be avoided by using polymorphism. >(Using the Liskov Substitution Principle is also a good idea) Yeah, I'd strongly concur here. From a maintainability perspective, you pretty much kill one of the main points of run-time typing if you have to itemize all potential types in your code. Have you or your guys used RTTI much with MSVC with third-party libraries? The integration/maintainability aspect (on Windows) is a point that I wouldn't want to become a burden. >* Inheritance structures to allow (multiple, single inheritance with >multiple interface, pure single) > >Multiple inheritance can be tricky. >I would like to use single inheritance (for IS-A relations) >And multiple interface inheritance (for IMPLEMENTS relations; the same >interface can apply to different kind of (otherwise unrelated) objects) Sounds exactly like what I was calling single inheritance with multiple interface, and sounds like from your message and others that we're all pretty much on the same page here. >I would like to precede interface type names with an 'I' (e.g. >IRotatable, IScalable, IColorable) This is undoubtedly a bike shed issue (you either like them or you don't and it's based on familiarity), but how about just Rotatable, Scalable, Colorable, Mutable, etc? Conversely, could use a verb-adjective "Is" descriptive that avoids the unnamed prefix but retains an identifier consistent across all interfaces: class Geometry : public IsScalable, public IsRotatable I'd still probably be more of a fan for unqualified, though: class Geometry : public Scalable, public Rotatable Coming from one of the most obtusely prefixed and name-mangled libraries out there (BRL-CAD), I'm 'usually' (there are always exceptions) pretty opposed to unqualified prefixes/suffixes that might make a new developer hunt the documentation or ask a question to find out what it means. The arguments for and against them aren't really any different than those for full-blown Hungarian notation (which these days at least I think 'most' have come to appreciate as a 'bad way' to embed meta data about types). The very nature of using an adjective instead of a noun for the class name indicates that it's an interface. :-) Having a non-interface class with an adjective name would be pretty bad.. (and as an aside, if the only purpose of the interface is to provide introspection, I'd even drop the interface class and go data-driven instead to avoid the complexity and overhead) >* Communication (mailing list, forum, irc, hybrid) >A forum. IRC does not work here at TNO. :( Good to know. A forum seems to be the resounding preference per the website poll too. IRC doesn't really work for ARL either, but there are remote methods over SSH that can help. It's a shame really too, because there is so much power when all of the development team can interact in real-time with instant change notifications. We'll have to put something better than the sf.net forums in place if it's going to get used a lot more than it is now. Cheers! Sean ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
