Mateusz Loskot wrote:
Zachary Turner wrote:
On Mar 3, 2010, at 12:07 PM, "Simonson, Lucanus J" <lucanus.j.simonson@intel.com> wrote:
Usually I think of properties as something attached to an instance of a class without the need to modify the class.
class Person { string Name; Person() : Name() {} };
Person p;
Property<int, Person> Age(-1); //default age is -1, an error code
Age.set(10, &p); assert(Age.get(&p) == 10);
Such a thing becomes rather complicated once you try to wire in removal of property values to the destructor of your object type and duplication of property values to the copy constructor without the need to know about all the kinds of properties that might be later associated with the class at the time the class is defined. Add to that custom heaps for storing property values and clever schemes to look them up and you quickly run into a system that is quite complicated with singletons running around and issues with thread safety etc etc. I think it is better to keep things simple where possible and understand clearly what the problem is and why the problem requires a complicated solution before implementing or using a complicated solution.
I think conceptually the proposed abstraction fits my mental image of "properties" pretty closely, and probably the same for anyone who has made significant use of C#.
The main problem they address is providing a level of abstraction over data members allowing you to have logical properties as opposed to physical properties. This allows you to change the implementation details of a class without changing its interface.
I'm not sure about that. I don't recognize a big difference between use of C# properties:
int age = person.Age;
and C++ member function:
int age = person.get_age();
In fact, I should write it this way, to mimic C# syntax closer: int age = person.age(); person.age() = age; Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org