Hello .NET, D Here Calling

Daniel de Kok me at nowhere.nospam
Tue Dec 23 14:03:10 PST 2008


On 2008-12-23 22:10:53 +0100, "Nick Sabalausky" <a at a.a> said:
> 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

I happen to disagree :^).

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

It *does* provide more encapsulation, since you could modify the getter 
or setter without changes for the called. This was supposed to be one 
of the advantages of encapsulation (and it is).

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

I agree, and am not to fond of operator overloading. Of course, in C++ 
it is pretty much unavoidable for assignment and comparison. There is a 
place for operator overloading, e.g. in math labraries. But I don't 
like overuse of operator+ for, say, assigning widgets to some 
container, or operator* for string multiplication (as in Python).

But I guess there's also much taste involved, some people don't like 
verbosity ;).

-- Daniel




More information about the Digitalmars-d mailing list