Re: [boost] Another implementation of properties.

Subject: Re: [boost] Another implementation of properties.
From: Zachary Turner (divisortheory_at_[hidden])
Date: 2010-03-03 14:21:20

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.

Aside from syntactic sugar (in C# anyway) there is no difference  
between properties and get/ set methods.  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.

Im not defending or criticizing this implementation, just speaking in  
general.

Zach