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