Properties: a.b.c = 3

[Benji Smith]

Nick Sabalausky wrote:
> "Zhenyu Zhou" <rinick at gmail.com> wrote in message 
> news:h4rfif$2os2$1 at digitalmars.com...
>> e.g.
>> Rectangle rect(Rectangle r) {
>>  _rect = r;
>>  redraw();
>>  return _rect;
>> }
>>
>> If you allow
>> widget.rect.w = 200;
>> widget.rect.h = 100;
>> you will have to write much more code to handle the painting correctly.
>> and we don't want to call redraw twice here
>>
> 
> I've dealt with that sort of thing in C# and it's a trivial issue. When you 
> write code such as the above, it's very clear that you're changing the rect 
> twice. If that's a problem, you just do this:
> 
> widget.rect = Rect(200, 100);
> 
> Easy. 

It's kind of a moot point anyhow, because most respectable graphics 
frameworks will defer any rendering until all properties have been set. 
Something like this:

    class Rect {

       private int _w;
       private int _h;
       private boolean _dirty;

       property set w(int value) {
          _w = value;
          _dirty = true;
       }

       property set h(int value) {
          _h = value;
          _dirty = true;
       }

       void draw() {
          if (_dirty) {
             // rendering code
             _dirty = false;
          }
       }

    }

Rendering code is *never* invoked from within a property-setter, and 
property values are never changed during rendering code. (Also, there's 
usually a separate "measurement" phase, following the manual 
property-setting phase, within which properties can be changed to suit 
the positional constraints but where no rendering occurs.)

Anyhow, I think those kinds of considerations are mostly orthogonal to a 
discussion of properties, in the general sense, except insofar as the 
existence of a property syntax makes it more convenient to implement 
things like dirty-flag marking, property-change listeners, and the like.

--benji