@property - take it behind the woodshed and shoot it?
TommiT
tommitissari at hotmail.com
Mon Jan 28 09:52:44 PST 2013
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.
More information about the Digitalmars-d
mailing list