[boost] Re: class properties: request for promotion and/or fastreview.

From: Edward Diener (eddielee_at_[hidden])
Date: 2004-05-23 12:37:48

David Abrahams wrote:
> "Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> writes:
>
>> It's not more nor less safe as usual get/set scheme.
>
> Oh, one other point: the main reason for the "usual get/set scheme"
> isn't safety, per-se, but encapsulation.  The interface can remain
> stable while the implementation changes so that there is no data
> member of the type being accessed.  If your properties library doesn't
> have that property (I don't know whether it does or not), it isn't a
> substitute.

I agree with you that encapsulation is a good reason, but getters and
setters can offer the same encapsulation while hiding the implementation
details. Some other reasons why I like properties:

1) I like the syntactic sugar of x.y = avalue as opposed to x.Sety(avalue).
It also seems more natural to treat data values which have the backing of a
function call in the former way rather than the latter way. The syntax is
the same as manipulating a value, which is the way I think of properties
anyway.

2) Is is Setx(avalue) ? Is is setx(avalue) ? Is it (pP)utx(avalue) ? etc.
With properties it is just x = avalue. Much easier to remember.

3) Properties can serve as RAD types and make it easy for a RAD tool to do
things with "properties". They can be actual types as opposed to using a
naming convention, such as JavaBeans implements, and which is so easy to
forget. Sometimes easy to program is best. RAD tools which work off of
types, and not names, are more robust, easier to use, and easier to program
originally.