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