3 ms·

The first point: > (...) My question is how often has the working programmer ever had to do that? I don't remember ever doing this in all my years of software.

by sgift 9y ago

The first point: > (...) My question is how often has the working programmer ever had to do that? I don't remember ever doing this in all my years of software. has that hollow ring of "I write my software the way it doesn't allow easy changes, so I don't do them, so there's no reason to do it." ... there probably would've been reason to do it more than once, the author just didn't want to do it because it would've been painful. Anyway: If you can make your class work without exposing anything then go ahead. That's great. But if you have to allow external access a getter will always be better than direct access. p.s.: Setter means mutable class. Mutable classes are a performance hack. Sometimes you have to do it, most of the time it's premature optimization.

sakuronto 9y ago
> Mutable classes are a performance hack. Could you please clarify this point? I have no idea what you're trying to say.
- jacques_chester 9y ago
  It's often much faster to modify something in place than to create a modified copy. Suppose I have: Point point = new Point(50, 50); int x = 100; int y = 200; Point translatedPoint = point.plus(x, y); // new Point(this.x + x, this.y + y) This code suggests that Point is immutable. Once defined, a point never changes. This makes a lot of sense -- if you change the values of x and y, you have a different point, in a mathematical sense. But newing up an object is tremendously slower than integer arithmetic. Suppose I can do this: Point point = new Point(50, 50); point.translateX(100); // this.x += x point.translateY(200); // this.y += y Point translatedPoint = point; This is going to lead to translatedPoint much more quickly than the first code. But it's riddled with troublesome outcomes. Who else was relying on point? What happens if I change it again? Why am I able to mutate something that, mathematically, isn't mutable? The basic reason mutability improves performance is that you can change things in-place without making a new copy. Most of the stuff being done during the copy construction is overhead compared to the thing you're changing. The price might be too high in a performance-sensitive situation. There are workarounds based on using copy-on-write datastructures with clever shared bits, but they're not native idioms in Java-land or in most languages without a strong functional heritage.
- sgift 9y ago
  Immutable classes are far easier to reason about than mutable classes. You run the constructor and know "this instance won't ever change again" - but it means if you want a change you need to create a copy with the changed data, which can be a performance problem if you have to do it very often. See the difference between GregorianCalendar (or Date) and the more current java date APIs. The new ones are immutable and every "mutable" operation returns a new object instead of changing the old one.

by sgift 9y ago

sakuronto 9y ago

> Mutable classes are a performance hack. Could you please clarify this point? I have no idea what you're trying to say.

jacques_chester 9y ago
It's often much faster to modify something in place than to create a modified copy. Suppose I have: Point point = new Point(50, 50); int x = 100; int y = 200; Point translatedPoint = point.plus(x, y); // new Point(this.x + x, this.y + y) This code suggests that Point is immutable. Once defined, a point never changes. This makes a lot of sense -- if you change the values of x and y, you have a different point, in a mathematical sense. But newing up an object is tremendously slower than integer arithmetic. Suppose I can do this: Point point = new Point(50, 50); point.translateX(100); // this.x += x point.translateY(200); // this.y += y Point translatedPoint = point; This is going to lead to translatedPoint much more quickly than the first code. But it's riddled with troublesome outcomes. Who else was relying on point? What happens if I change it again? Why am I able to mutate something that, mathematically, isn't mutable? The basic reason mutability improves performance is that you can change things in-place without making a new copy. Most of the stuff being done during the copy construction is overhead compared to the thing you're changing. The price might be too high in a performance-sensitive situation. There are workarounds based on using copy-on-write datastructures with clever shared bits, but they're not native idioms in Java-land or in most languages without a strong functional heritage.
sgift 9y ago
Immutable classes are far easier to reason about than mutable classes. You run the constructor and know "this instance won't ever change again" - but it means if you want a change you need to create a copy with the changed data, which can be a performance problem if you have to do it very often. See the difference between GregorianCalendar (or Date) and the more current java date APIs. The new ones are immutable and every "mutable" operation returns a new object instead of changing the old one.