Michiel Helvensteijn wrote:
BLS wrote:
I think people got it. But it's not a property. Your one-liner seems to
be equivalent to a field. Except, I guess, that you can't take the
address.
The whole idea of a property is that it can have non-trivial
getter/setter functions. Like a read-only property of a Line, that
returns its length automatically calculated from its two points. Or a
getter and setter that keep a log of all accesses to the information.
My favorite example is of a Color class, that internally stores its value
in the RGB model, but has properties to read and change its value through
the HSV and HSL models as well.
...
Again, what is the difference between your one-liners and simple fields?
immutable property uint theAnswer = 42;
bool has_cojones;
A property is much more sophisticated. The whole point is to write your own
setter and getter methods. Only in very few cases do you want a property
with simple field semantics. I will give you that Line class I was talking
about. Tell me how you can do this with your one-liner:
class Line {
private:
Point _a;
Point _b;
public:
this(Point a, Point b) { _a = a; _b = b; }
property float length {
auto get() {
float absX = abs(_a.x - _b.x);
float absY = abs(_a.y - _b.y);
return sqrt(absX * absX + absY * absY);
}
}
// insert trivial properties to read/write points
}
You see, the length property doesn't have its own storage. It deduces its
value from the points of the line.
I don't agree .
1- In most cases we have to deal with simple field semantics, No ? x,y,z
so : immutable property uint theAnswer = 42; is a getter()...... period.
your calculated length property is an exception, should be written in
standard D code.
IMO a property is a simple thing, a color, a weight, or a mass...
