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

From: Edward Diener (eddielee_at_[hidden])
Date: 2004-05-23 19:02:52

David Abrahams wrote:
> "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 didn't. I was making an argument for properties as values and not
necessary variables. If they are merely a substitute for variables, they can
be seen merely as syntactic sugar for getters and setters. As much as I like
that because of my fondness for the data variable notation when accessing
and setting properties, I see the concept as extending beyond that and being
valuable as long as it is not overused.

>  I am, after all, a Python programmer.

I am also, although not as experienced with it as you are. Glad you like the
language. I can see your boost python implementation also so I knew you know
Python well.

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

I had assumed, without looking into it, that it attached getters and setters
to property values so that there was at least some protection for setting
them and possible transformations for getting them. I guess I made a naive
assumption myself.

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

You can already guess no doubt that I found Allen Holub's arguments pretty
weak.

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

My point was merely that I don't believe having properties, as in those
frameworks, is any impediment to abstraction. Even if they didn't use
language/compiler extensions to do introspection, I would still feel that
way although of course properties would be less useful for the lack of RAD
capabilities associated with them in those environments. I understand the
argument that the less reliance on particular types of data itself, the more
easily a concept can be abstracted and changed without affecting the outside
interface ( public or protected ), but almost all concepts must be modeled
on some idea of data being manipulated and properties offer another possible
alternative to safe data manipulation in the right situations. Associating
properties with less abstraction is equivalent to saying that the less data
a class entails the better off it automatically is in OO design terms.

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

I would too, and I am glad we agree that they have their value. Perhaps a
library flexible enough to do it hasn't been written yet, or perhaps it can
not be written given C++ as it exists. Anyway it is a moot point unless I
were willing to tackle it myself, and I agree that I haven't seen a library
with enough flexibility to mimic the sort of properties in Borland and MS
that is needed for C++ programmers. Having used C++ Builder properties and
.NET properties in practical situations I can attest to their making certain
tasks of programming and design easier for myself. Of course I can't speak
for others.