Nick Sabalausky wrote:
"Zhenyu Zhou" <rin...@gmail.com> wrote in message
news:h4rfif$2os...@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
