Hello .NET, D Here Calling

[Nick Sabalausky]

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

It's far more than a mere presumption:

class Foo{
  public int x;
}

// vs

class Foo{
  private int _x;
  public int getX() {
      return x;
  }
  public void setX(int x) {
      _x = x;
  }
}

It would take a Java mentality to find the second to be every bit as good as 
the first. Yes, it's functionally equivilent, but it's a horrid mess and 
provides absolutely no benefit in a language that supports properties. Note 
also, that the second form provides absolutely no more encapsulation 
benefits than the first. The only reason that idiom was ever created in the 
first place, and the only reason it's ever used (and the only reason public 
member variables were ever deemed to be bad style in the first place) is to 
provide an "upgrade path" in case more functionality is needed. Properties 
render that all irrelevant, and allow variables to once again be used for 
what they were actually intended for in the first place. (Also, they 
eliminate the need for getter/setter naming conventions.)

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

Debatable, there are reasonable arguments on both sides (Personally, I find 
the latter to be a case of "mixing different levels of abstraction" and thus 
poor design for the same reason that not using functions is poor design: 
Implementation details *should* be abstracted away so they don't obscure the 
high-level concept of what you're doing. Take a look at the iterators and 
explicit (un)boxing in older versions of Java to see what a horrendous 
unreadable (and slow-to-develop) mess code becomes when you expect every 
line of code to be transparent.)

But regardless, if you're one of the many people that accept operator 
overloading, then the debate is moot: Operator overloading is every bit as 
capable of making what looks like a trivial operation do non-trivial things.

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