class properties in c++

[Rob Wehrli]

> So anyways,
>
> I was thinking maybe a good idea for getting/setting properties would be
> like this:
>
> RETVAL PropertyName();
> void   SetPropertyName(RETVAL *var);
>
> with RETVAL being the data type of the property being set. My reasoning
for
> this approach, and not one that returns an error code, is because it would
> at least seem that the error handling would be taken care of by the class
> itself(since this is C++ and not C).
>
> What do you guys think?

I'm not sure that I correctly understand what you're trying to accomplish.
The entire idea behind a function in C++ is to live up to its contract.  It
essentially says "in writing" that if you give me a pair of ints I'll return
you their sum( int a, int b ) else I'll throw an error.  This implementation
seems appropriate for simple types, however, in implementations, you'll
often find return codes of some value other than zero used to indicate an
error condition.

int DisplayText( ... );

If the display device is not available, perhaps you'll get a particular int
back.  If the default functionality is to print a single line of text and
you send it a book, perhaps yet another error code value, however, in some
cases, the function may "work" to some extent (such as print the first full
line) and return the error code to you so that you will know how it treated
the "agreement" of its contract.  Perhaps you're filling a buffer and
looping through your code to call a function that writes data out to the
buffer waiting for some result that means its full or perhaps more likely,
can take more data.

These kinds of implementations are typical throughout the world of all kinds
of programming because they readily facilitate easy use and understanding
without being too difficult to learn to use correctly.  They are not
necessarily "preferred" for any number of programming challenges, but there
is something to be said about something that works well out of the box.

In your example/thinking above, you should consider naming your functions as
verbs.  DoSomething( ).  WalkDog( ).  FeedBird( ).  ClimbStairs( ).
GetProperty( ).  SetProperty( ).  Close( Connection &con )...etc.  This is
the "naming" issue that Dave was probably trying to communicate.  Your
functions should clearly describe what they're doing for you so that
confusion is avoided and so that people can readily understand how to use
them and why they'd want to use them from a quick glance at just their
names.  There are perhaps a billion different cool ways to use return types
for some elaborate meaning/representation of what went on inside your
function, but equally elaborate is the challenge of trying to make it a
consistent theme across functions of various types and work objectives to
the point that you're more likely to really confuse the hell out of anyone
using your code...even yourself!  Remember that the simplest thing that
works is probably a good thing.  I'd avoid function names that do not convey
a clear message, such as PropertyName( ).  Does this function name a
property?  Does it retrive the prop's name?  The key here is that the verb
is unclear.  The action is unclear.  We're not explicitly telling our user
(of the function) why they're calling it and what real value (work) they're
getting from it.  That is why Dave correctly recommended using Getters and
Setters to access and mutate members of your classes.  At some point though,
you're going to have real work that doesn't happen in an accessor or mutator
function, err method.  At that point, life is a little less clear and the
whole world of opportunities abound...which really make your decision making
process much more challenging.

DisplayText( ... );

What should its parameters/arguments be and what should it return?  Remember
that functions that take no args and return nothing are of very little use.
run( ) is about the only instance that readily comes to mind.  Even sleep( )
takes an interval arg :)

>
> Not to get you guys off-topic, or anything :)

Big Grin.  I'm at least doubly guilty on this particular occasion.  I often
just walk away from such, but this is "my" list, too.  On a "home" list, I'd
like for the "ground rules" to be clear among contributors, and that is to
get along and keep the fact that we're all "peers" here in mind.  Each of us
has valuable and varied skills to bring to the table.  It doesn't do for
anyone, me included, to "hog the foreground" or "bully" conversations.  I
hope that Dave will react to my rather stinging reply in a positive manner
and become a valued contributor to this forum, but if not, well, we don't
need BS messages and BS "filters" clogging up the bandwidth on this list.  I
hope that if I get out of line, someone will point me back to the straight
and narrow, too.

>
> Thanks,
>
> Lucas
>

Take Care.

Rob!