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