class properties in c++

[Lucas Vogel]

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

I don't know what I was thinking - perhaps I should've poked around my
reference books before throwing that one out. 

But what I was originally thinking was for [class, object] "properties" -
getting/setting values in a [class, object] for its contained data types -
the [method, function, contract] that "gets" the value would have a return
type of the data type it was retrieving, while the "set" would be a void
that passes in the value of the data type being set. Neither one of the
[functions, methods, contracts] would return any error-related values
because it would be handled within the calling[function, method, contract]. 



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

This goes back to my original question - do I set up my properties as
SetXX() and GetXX() [functions, methods, contracts]? The MS platform defines
them as [functions, methods, contracts] with a get_ and put_ prefix.


thanks,

Lucas