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

Subject: Re: [boost] [property] interest in C# like properties for C++?
From: Olaf van der Spek (olafvdspek_at_[hidden])
Date: 2009-10-23 12:22:41

On Fri, Oct 23, 2009 at 5:33 PM, Edward Diener <eldiener_at_[hidden]> 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