@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