No problems here for me. I can live with unqualified. I also don't like
Hungarian notation. The only reason for using the 'I' would be to make
it more in line with naming conventions in Java and C#. 

I'd only use interfaces for preventing too much coupling between
methods/classes: using an interface as a restricted view on an object.
What do you mean by introspection? Querying an object for having an
interface and then using the appropriate methods? I'm not sure if I like
this. 
Can you give an example of the 'data-driven' approach?

Wim

-----Original Message-----
From: Christopher Sean Morrison [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 27, 2008 1:37 AM
To: Bokkers, W.Chr. (Wim)
Cc: [email protected]
Subject: Re: [brlcad-devel] BRL-CAD C++ Geometry Engine

>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)

Cheers!
Sean


This e-mail and its contents are subject to the DISCLAIMER at 
http://www.tno.nl/disclaimer/email.html


-------------------------------------------------------------------------
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

Reply via email to