Hello .NET, D Here Calling

[Nick Sabalausky]

"Daniel de Kok" <me at nowhere.nospam> wrote in message 
news:gir3fq$1qjt$1 at digitalmars.com...
> On 2008-12-23 11:47:56 +0100, Chad J <gamerchad at __spam.is.bad__gmail.com> 
> said:
>
>> Lutger wrote:
>>> I noticed many developers really adore properties, perhaps it's worth 
>>> some attention to rethink how this is handled in D. It is used 
>>> everywhere in .NET.
>>
>> This is exactly where I'm coming from.  I used to use C# properties a
>> lot.  They are super effective.
>
> With no intention to flame, but I never quite understood why people are so 
> keen on properties over getter/setter member functions. What advantage 
> does it have over obscuring direct member access and indirect member 
> access?
>
> I think that the D approach is good enough, since it does not add 
> complexity for library designers.
>

Library designers are exactly the people that properties are great for. They 
allow you to expose a "property" of a class in a way that can be changed 
back and forth between a variable and get/set functions without ever 
breaking a single line of the library user's code.

For instance, suppose you're writing a class for "Paint", and you want the 
user to be able to choose and query the color. Sounds to me like a job for a 
variable. Set/get functions would be overkill. So you do that, release 
PaintLib v1.0 and people use it and everything's good. Then later, you 
decide to add some sort of logging that occurs whenever the paint color is 
changed. Or maybe trigger an animation, or something. Now, "Paint.color" 
needs to be setters/getters. So you change it to set/get functions and break 
everyone's code. "Gee, thanks".

Developers in older languages like C++ have gotten around this by learning 
to religiously make everything set/get functions from day one. This is 
overkill, a pain in the ass, and with properties, completely unnecessary.

And then there's another reason:

foo.x += 7;

Is a hell of a lot nicer than

foo.setX(foo.getX + 7);

There are ways to improve on that second one, but they all led to either 
hackiness or odd fringe cases or just simply "still not as good".