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.
Regards, Luke
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 both cases change of implementation details without touching the interface is possible. It feels more like a syntactic sugar. Though, properties in C# seem to provide better self-containment and property isolation than regular methods.
Aside from syntactic sugar (in C# anyway) there is no difference between properties and get/ set methods.
That's right. C# compiler generates proper setters/getters for properties anyway.
In C++ i can see potential benefits with respect to generic programming-- if data members are get/set with an identical syntax to how functions are called yhey can be used as policy classes which expect certain members being present.
It is still possible, by defining a convention as it happened with well known members like size(), begin(), end() or definitions like value_type, size_type, and so one.
Im not defending or criticizing this implementation, just speaking in general.
So do I. By the way, Visual C++ provides an interesting attribute: __declspec( property(...)) http://msdn.microsoft.com/en-us/library/yhfk0thd%28VS.80%29.aspx Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org