On Fri, Oct 23, 2009 at 5:33 PM, Edward Diener <eldiener@tropicsoft.com> wrote:
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.
Don't you agree that string& name = c.name; name.size() is kinda ugly/unusable compared to just c.name->size() (possible) or c.name.size() (not possible, but ideal)?
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.
The main goal I guess is 1, as the others can be achieved with traditional get/set functions, right?
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.
That's right. And actually why I wanted to use a class reference property.
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.
I know, and I agree.
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
Hmm, I'd consider such C++ implementations broken by design. Olaf