Olaf van der Spek wrote:
On Fri, Oct 23, 2009 at 3:40 PM, Edward Diener <eldiener@tropicsoft.com> 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.