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

From: David Abrahams (dave_at_[hidden])
Date: 2004-05-23 17:50:49

"Edward Diener" <eddielee_at_[hidden]> writes:

>> When classes have a lot of getters and setters or, equivalently,
>> exposed properties that are just reflections of underlying data
>> members, they usually represent just a collection of exposed data
>> values rather than a higher level of abstraction.
>
> Properties do not have to be data members at all but just values may be set
> anywhere, ie. a file on disk or a database, and a number of properties may
> refer to a single underlying object within the actual object having the
> property. 

I know all that.  Please don't assume I have a naive view of
properties.  I am, after all, a Python programmer.  I was talking
specifically of "exposed properties that are just reflections of
underlying data members".  Does Gennadiy's library enable another
kind of property?  If so, so much the better.

Anyway, I really suggest you follow the links I posted since I don't
really have time to have this argument myself.  I see both sides of
the issue, and would be happy for people to make up their own minds
when presented with all the information.

> As such I don't think that having many properties necessarily is
> any impediment to a level of abstraction. Furthermore properties of a
> derived class may actually affect some underlying functionality of a base
> class, which I don't see as any more an impediment to designing a good class
> hierarchy than calling a member function which uses base class functions to
> achieve its functionality.
>
> It could be equally as right to say that a class having many member
> functions does not represent a higher level of abstraction, but I think that
> this is an incorrect argument also. Cleary frameworks such as the VCL and
> .NET can present fairly high levels of abstraction for whatever concepts
> they are modeling for application development and each use properties very
> effectively to make it easier to program their respective frameworks.

That's a whole different ballgame from what's under discussion.  The
stuff that makes these properties work well in their frameworks has
everything to do with introspectability and nothing to do with the
syntactic sugar provided by properties.

> I do agree that an overuse of properties is a theoretical danger to
> programmers who may become so enamored of them that they substitute
> functionality for setting values and thus hide what should be functionality
> behind an obfuscated interface. But C++ has always been a language which has
> promoted best programming practices rather than protection of novices and I
> see no reason not to do this in the matter of properties also.

I would like to have properties in the language, in part because they
would increase expressivity and allow better DSELs to be written.  The
library substitutes are not good enough for me, though.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com