Hello .NET, D Here Calling

[Daniel de Kok]

On 2008-12-23 20:09:56 +0100, "Nick Sabalausky" <a at a.a> said:

> "Daniel de Kok" <me at nowhere.nospam> wrote in message
> news:gir3fq$1qjt$1 at digitalmars.com...
>> 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.

So can they do with getters and setters.

> 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.

Some would call it overkill, some would call it proper encapsulation. 
Personally, I never allow direct access to member variables (except for 
types that have no 'behavior'). It comes at virtually no extra cost, 
and there is a good chance that simple setters will require some 
validation or locking in the future anyway.

> So you change it to set/get functions and break everyone's code. "Gee, thanks".

That wouldn't happen, since I'd use getters/setters anyway ;). So far, 
the only advantage is the presumption that getters/setters are overkill.

> And then there's another reason:
> 
> foo.x += 7;
> 
> Is a hell of a lot nicer than
> 
> foo.setX(foo.getX + 7);

Maybe, but in the setter case you can explicitly see what is going on. 
Would you expect something that looks like a variable assignment to 
throw an exception or to perform validation?

Not that I religiously want to debate against properties, but I think 
C# has its amount of feature-creep, and I think this is one of the 
things one could easily do without. But then on the other hand, a lot 
of people are also happy with Java, which misses basic things like 
typedefs ;).

-- Daniel