David Abrahams wrote:
"Edward Diener" <eddielee@tropicsoft.com> 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.