Re: [boost] Another implementation of properties.

Subject: Re: [boost] Another implementation of properties.
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2010-03-03 19:47:10

Zachary Turner wrote:
> On Mar 3, 2010, at 12:07 PM, "Simonson, Lucanus J"
> <lucanus.j.simonson_at_[hidden]> 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