On Monday, 28 January 2013 at 17:30:40 UTC, Dicebot wrote:
Let's say your type has three properties:
#1: start_time
#2: end_time
#3: duration
Changing any one of those properties must (logically) change
at least one other property. Therefore, you can't just pretend
that properties are simple data fields.
That is no different from volatile variables.
If you think my example of {start_time, end_time, duration}
represents proper use of properties, then I don't see why you
oppose array.length. To me it seems like the same thing. Array
has some length, and you can change it by changing its length
property. T represents a certain time range, and you can change
it by changing any of its three properties {start_time, end_time,
duration} which describe that time range.
My notion is at least same as C# guideline authors, so it
should be not that rare. It all comes from "property ==
variable" mantra.
I'm just saying that when you read some code written by some
person X, you can't rely on person X having the same notion of
what properties should be as you do. For this reason you can't
only read the documentation of methods and skip reading the
documentation of properties, because properties may do/change
things that you wouldn't have made them do/change.
