Nothing pollutes java source more than getters and setters. I can't believe this still isn't being address. Wish they'd move in the direction Groovy has in this regard.
Not exactly comparable (because everything is immutable), but Haskell has sort of a cool approach to setting and getting fields.
Let's say you have
data Point = Point {x :: Int, y :: Int}
If you have a Point object called "point", you can get x by doing
x_coord = x point
If you want to create a new Point with x set to 5, you can do
Nothing pollutes java source more than getters and setters. I can't believe this still isn't being address. Wish they'd move in the direction Groovy has in this regard.
It is addressed by better design. First off, it's important to know the difference between value types and objects. For a value type, public final fields are good. They are set in the constructor once, and can only be read, and can't change. Getters are pointless, and my code does not have them. If you want them for a reason, then intellij does an amazing job fixing that. Objects encapsulate mutable state, and getFoo…
> It is addressed by better design.
This! A lot of the horrible Java you see around is nothing but an artifact of mindlessly applying patterns to constructs that don't need them.
> a lot of java was created when we still hadn't figured out how to properly do Object Oriented Programming.
Which is quite unforgivable, considering Smalltalk has been around since the early 80's.
Sorry to ask, but as a noob who just picked up Java, how do other languages address this issue? What's wrong with getters and setters?
IMO Dart has the best implementation of properties, which you can start out as normal fields, e.g: class Rectangle { num left, top, width, height, right bottom; } and can access like normal: var height = rect.bottom - rect.top; But can later be changed into a computed property without affecting the above callsites, e.g: class Rectangle { num left, top, width, height; num get right => left + width; set right(num value…
Sorry to ask, but as a noob who just picked up Java, how do other languages address this issue? What's wrong with getters and setters?
IMO Dart has the best implementation of properties, which you can start out as normal fields, e.g: class Rectangle { num left, top, width, height, right bottom; } and can access like normal: var height = rect.bottom - rect.top; But can later be changed into a computed property without affecting the above callsites, e.g: class Rectangle { num left, top, width, height; num get right => left + width; set right(num value…
Why does it matter if it's binary compatible? How does that affect the programmer? I guess I don't understand the difference/significance between binary and source compatibility?
I'm surprised to hear that it's not reflection compatible. As a Java programmer, I assumed that was the main point of C# properties: Create a property now because there's no logic needed, but if you need logic in the future you can change the code and nobody outside needs to be aware of the change.
For c# just: public int Age{get;set;} no need to declare private variable, get or set methods.
And you can replace it with a virtual property in the future (changing the underlying implementation) without breaking anything. And user code ends up simpler and more readable too: foo.baz += foo.bar; vs. foo.setBaz( foo.getBaz() + foo.getBar() );
If you want to rid yourself of GC problems, go buy Azul's Zing JVM. It works like magic. (disclosure: I'm a very happy customer of theirs)
Zing does not do you any good if you are selling software. Your income is reduced by the license cost of Zing in addition to the additional sales and deployment friction. The reality is that you have to build software that works on the Oracle JVM.
Sorry to ask, but as a noob who just picked up Java, how do other languages address this issue? What's wrong with getters and setters?
In python the default is that things that look like attributes/properties REALLY are direct access. If you later need to shim them out into a function you use the @property decorator (and foo.setter if you need read/write) class Blah(object): foo = 2 # A normal property. Direct access @property def bar(self): return self.some_lookup_method() @bar.setter def bar(self, value): self.set_the_bar(value)
Thanks for mentioning this. I've found the Python approach works really well in practice.
Zing does not do you any good if you are selling software. Your income is reduced by the license cost of Zing in addition to the additional sales and deployment friction. The reality is that you have to build software that works on the Oracle JVM.
ah, understood. have you been tracking shenandoah? http://openjdk.java.net/jeps/189
I have heard of it but haven't read up. I think it's great that someone is stepping up to address the issue. Interesting that both the authors listed in the JEP work for Red Hat.
Nothing pollutes java source more than getters and setters. I can't believe this still isn't being address. Wish they'd move in the direction Groovy has in this regard.
It is addressed by better design. First off, it's important to know the difference between value types and objects. For a value type, public final fields are good. They are set in the constructor once, and can only be read, and can't change. Getters are pointless, and my code does not have them. If you want them for a reason, then intellij does an amazing job fixing that. Objects encapsulate mutable state, and getFoo…
I agree and I hate getters, but I am one of those who still hasn't figure out how to do OOP correctly. Do you have an example or maybe some suggested reading? For example, if I have a user object, with name, age, number, how would that work without get/set? I'd love to avoid it, I hate the bloat it creates, and also how frivolous it seems to test get/set.