DIP4: Properties

[BLS]

Bill Baxter wrote:
> On Tue, Jul 28, 2009 at 3:53 PM, BLS<windevguy at hotmail.de> wrote:
>> 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...
> 
> How is length not as simple as a color?  I don't get it.
> 
> And consider the case of complex numbers.  Either the pair (real,imag)
> is stored or (modulus,argument) is stored.  Neither is more
> "fundamental" than the other as a representation.  Which one do you
> make a field and which one "standard D code"?
> 
> --bb

hi bill,
my fault,
I mean  distance.. (instead of length)

Hope you agree with me that a colour (in the senses of E. Kant ) is 
something we can'T see as it is. but we gave and give it nevertheless  a 
name : likewise red. Does not mean too much just :RED is a propetry.

Now let`s compare that with distance calculation (without drifting too 
much away)
RED is a property, Distance means necessarily a calculation.
The question is ergo : Do we want pure behavior or math in our 
properties. IMO, behavior. This is what property means.

so imutable proberty bool killbillv2 = false
// is a read only getter ..

(However to answer : ref... delegate and you have everything you need)