Property Syntax Revised

rethought it again....

class SubString {
private:
   int mEndIndex;

public:
   // the type after the keyword 'property' defines the
   // type of the value member of the property.
   // void means there will no value be stored
   property void length;
   property int  beginIndex;

   SomeClass(void) : beginIndex.value( 0 ) {}
   virtual ~SomeClass(void) {}

   int length::set(int value) throw() {
      if( value < 0 )
         throw out_of_range("SubString::length::set(int value): value < 0");

      // the attribute value is allways private
      // except the property is virtual, then it's protected (good idea? don't know)
      // or would it be better, when it where allways protected?
      mEndIndex = value + beginIndex.value;
      // the setter has to return a value, so the compile has not
      // to call the getter in expressions like i = (obj.prob = j);
      return value;
   }

   int length::get( void ) const {
      return mEndIndex - beginIndex.value;
   }

   int beginIndex::set(int value) throw() {
      if( value < 0 )
         throw out_of_range("SubString::beginIndex::set(int value): value < 0");

      // this->value would be confusing
      return beginIndex.value = value;
   }

   // hmm... or if no beginIndex::get() is declared then it will be accessed directly by default?
   // this would be a easy aproche but IMHO not clean.
   // this way you can define a readonly property be NOT declaring/defining ::set()!
   property int beginIndex::get( void ) const {
      return beginIndex.value;
   }
};

better example, a std::string property:

class SomeClass {
public:
   property string str;

   SomeClass( void ) : str.value( "initial value" ) {}
   virtual ~SomeClass( void ) {}

   // don't copy the string but allow only read acces through get()
   const string & str::get( void ) const {
      return str.value;
   }

   const string & str::set( const string & value ) {
      return str.value = value;
   }
   
   // so it's possible to do this in addition:
   string & str::get( void ) {
      return str.value;
   }
   
   // or this:
   const string & str::set( const my_string & str ) {
      return str.value = str.to_stdstr();
   }
};

Didn’t they do something with C++ with extensions to the specification?
__property int Width = {read=FWidth, write=SetWidth, default=200}

Before I wrote the article I googled for property syntaxes in various languages, and some site mentioned a property attribute for C++. I don't know whether it was Borland though. The syntax is not impressing though. My focus is to make it short, readable and easy to remember; I don't think that this syntax achieves these goals.

Modeling the get/set blocks to look so much like methods causes excessive verbiage.

It's certainly shorter with the value keyword, but it causes a special case in the grammar. You could, with the same argumentation, also simplify the syntax for operator overloading.

Basically, you are doing away with the idea of fields altogether… and replacing them with properties.

Yes. Think operator overloading for fields.



If this is the case, I think one should be allowed to specify the get and set for a private field too. Aesthetics.



The syntax allows it, and actually it doesnt matter, because (unlike Java) the accessor methods can not be used as methods. So there's no reason to forbid it.



Another aesthetic problem I have with this is the lack of a raw declaration for the length property. I know, the accessors aren’t going to be using its value so it isn’t really needed, but I think it should be included for consistency.



I also hesitated because of this one. The argument that I convinced myself with is that the property declaration is redundant. And the programmer should not be forced to do redundant declarations.



The major qualm I have is the potential confusion WRT the raw value VS the get/set accessors. Their is no confusion with C# style properties as the private fields that hold the value are not directly tied to the property.

I see the problem... what about this: you can either declare a property with the field syntax, OR write accessor methods, but never both. In other words, no ambiguity, no '@'. If you write accessor methods you need to add a private field if you need storage.




I think this style further erodes the idea of a field and makes them even *more* like methods.



It makes them more flexible: you can change them later without breaking anything. This includes changing the design of a super class with protected fields without breaking the compatibility for subclasses.