Re: [boost] [property] interest in C# like properties for C++?

Subject: Re: [boost] [property] interest in C# like properties for C++?
From: Edward Diener (eldiener_at_[hidden])
Date: 2009-10-23 11:33:06

Olaf van der Spek wrote:
> On Fri, Oct 23, 2009 at 3:40 PM, Edward Diener <eldiener_at_[hidden]> wrote:
>>> Maybe I should've said class reference. Take std::string for example.
>>> I'd be very interested if you've got code that supports for example
>>> name.size() where name is your reference property class. name->size()
>>> is no problem, but I'd like to have name.size().
>> I understand your point, and you are right, and this is a notational
>> weakness as compared with accessing the data directly.
>>
>> I don't believe that one can define a dot ( '.' ) operator in C++ but maybe
>> there is a metaprogramming way to hijack the dot operator. If there is I
>> would be glad to use it.
>>
>> Actually I have rejected defining the -> operator for my reference
>> properties, because -> implies a pointer in standard C++ terminology and I
>> do not think of reference properties "pointing" to their type object.
>> Instead my reference properties have currently no built-in forwarder
>> operator to the actual type object. One could currently use the more
>> laborious form of:
>>
>> propertyReference<std::string> name;
>> std::string & avar = name; // read/write property reference getter
>> avar.size() = 10; // or
>> std::string::size_type sz(avar.size());
> 
> Unacceptable
> 
>> or one could use my getter member function so one could write:
>>
>> propertyReference<std::string> name;
>> name.getReference.size() = 10; // or
>> std::string::size_type sz(name.getReference.size());
> 
> Unacceptable
> 
>> Using a member function rather than an operator in this case is just a
>> little more inconvenient.
> 
> For me, the access syntax of properties is *the* reason for using them.
> Otherwise you might as well just add string& name() and void
> set_name(const string&) functions to your class.
> What are your goals/reasons to use properties?

You are not talking about the access syntax of properties, as I define 
it, so your "Unacceptable"s mean little to me. Of course if the syntax 
limitations of a property implementation vis-a-vis direct manipulation 
of a data value is unacceptable to you, then you just wouldn't use it.

My interpetation of the access syntax of properties is:

1) For a readable value property, one can use the name of the property 
to return the underlying value of the property and assign that value to 
a variable.
2) For a writable value property one can set the value of a property by 
assigning a value to it.
3) For a readable reference property, one can get a reference to the 
property.
4) For a writable reference property, one can get a non-const reference 
to the property.

My main goals/reasons for properties are:
1) Syntactically treat a property as close as one can as a data member 
while providing the ability to control the accessing of the data and the 
setting of the data through callables ( functions, member functions, 
functors, boost::function ).
2) Have properties be a type.
3) Have all value properties of an underlying T type share an underlying 
base class and have all reference properties of an underlying T type 
share an underlying base class.
4) Provide means beyond just member functions for getting and setting 
values and getting references.

I have more than just these goals, but the above are the main ones.

Properties are in one way syntactic sugar for the plethora of 
get/retrieve/etc. and set/put/etc. member functions. I also acknowledge 
that it is syntactically impossible to manipulate properties as directly 
as one can manipulate data members as far as I can see. But properties 
are really not a substitute for data members but rather for get-like and 
set-like functions whose purpose is to access and manipulate a data 
value. After all, in my view of value properties, the data does not have 
to exist in memory at all, and I believe this is consistent with the 
implementation of properties in other languages.

Of course you can use "string & name()" and "void set_name(const string 
&)" if you like instead, or you can even just have a public variable of 
"string name" you directly access and manipulate. I can offer my 
criticism of the first choice or the second choice but I think it is 
already well known.

> 
>> My member function is actually currently called "getValue" for my reference
>> property but I have decided that it is a confusing name since one is really
>> getting a reference, and have changed it to "getReference".
> 
> How about just get()?

I rejected this because of a feeling that some implementations of C++ 
may macroize ( create a C++ preprocessor macro ) from such a common term 
as "get". The same goes for "set". I am aware that ideally macros should 
  be all uppercase, but many implementations and header files which 
should know better are deficient and forget this. Of course I can use 
"get" and "set" as the OP did in his C#-like property implementation, 
but I felt that getValue, setValue, getReference, and setReference were 
less likely to clash.