Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Data Classes for Java

cr.openjdk.java.net

Post reply on HN
Print view View original

121–130 of 216 posts

Re: Data Classes for Java

#121

Post by abiox »

cle wrote: post #97
chubot wrote: post #54

Earlier quoted context omitted.

Why don't you just use plain fields, and if you need to change it later, delete the field and go fix all compile errors? That's an easy way to find all usages. Or are you not talking about a statically-typed language which would find the errors when you temporarily delete a field?

You don't always control the code that uses it. You'll have a lot of angry customers if you break all their builds.

well, hopefully they aren't having the library update underneath them without warning. :P

Re: Data Classes for Java

#122

Post by HumanDrivenDev »

hackits wrote: post #58
HumanDrivenDev wrote: post #33

Earlier quoted context omitted.

But by definition getters and setters lack lexibility. They expose the internal representation of an object. They stop really being "objects" - high level opaque things you send messages to - and they turn into big porous bags of fields. To clarify, I would not consider something like this a setter: class Monster { int health; void Damage(int d) { this.health -= d; } } True, it is a method that just sets a variable.…

`Technically` The current representation of `objects` in java is a abomination to the original idea behind object's. Hell even the use of class, members and fields fly in the face of what real objects are.

What do you mean by "real objects"? Are you refering to prototype OO?

Re: Data Classes for Java

#123

Post by whitenoice »

vaskebjorn wrote: post #29
HumanDrivenDev wrote: post #2

... To write such a class responsibly, one has to write a lot of low-value, repetitive code: constructors, accessors ... If you're writing a plain data class, why on earth would you write getters and setters? Just make your fields public and be done with it. I will be forever perplexed by the idea of getters and setters (and this extends to C#s syntax sugar). I have no idea what problem they solve. If you're at the l…

In my experience writing getters and setters has been boilerplate 99% of the time. But I still write them because situations arise where you do need to change the nature of that property, sometimes dynamically, and then it's suddenly worth it. You can, for instance, change a getter and none of the class's clients need to know or care about the change. Though I haven't used Groovy much I like their approach to this: "…

You might want to look into Project Lombok. It does exactly that, and it works well.

Re: Data Classes for Java

#124

Post by HumanDrivenDev »

abiox wrote: post #120
wvenable wrote: post #105

Earlier quoted context omitted.

This seems to deny the fact that a lot of data exists to just be stored and displayed. Probably 85% of all software in the world has a "FirstName" field/property/column in it somewhere. What name you propose giving a method that changes that value?

if it's just used for display, use a new value. if there's more to the domain context, i'd call it rename(~). i think from the outside, it's better to articulate what you want in domain semantics, rather than implementation semantics.

i think from the outside, it's better to articulate what you want in domain semantics, rather than implementation semantics.

You've articulated here what I've actually been trying to communicate. I have no problem if a method does nothing but get/set a variable. I just think they should be named with domain semantics.

Re: Data Classes for Java

#125

Post by [deleted] »

Naac wrote: post #89
guelo wrote: post #37

Earlier quoted context omitted.

Not that nice compared to kotlin: data class Animal(dog: String, numberOfLegs: Int) val dog = Animal( name = "dog", numberOfLegs = 4 ) The amount of boilerplate for AutoValue builders is so ridiculous that most people use IDE plugins to generate it.

data class Animal(dog: String, numberOfLegs: Int) and Animal dog = Animal.builder() .setName("dog") .setNumberOfLegs(4) .build(); are very different. In this case the builder pattern is more powerful as it lets you pass around builders that haven't been "built" yet. Kind of like currying.

[deleted]

Re: Data Classes for Java

#126

Post by cakeface »

freeone3000 wrote: post #75
nikolay wrote: post #18

Why underscores in "__data"? Is this just a temporary thing?

Java reserved words are reserved in all contexts. You can't have a variable called "class" because class is a reserved word. If 'data' becomes a reserved word, imagine the code that would no longer compile...

Not exactly true, but true for this use case. The new module keyword in Java 9 is only a keyword in module-info.java. You can still have a variable named module in regular class files. They wouldn't be able to pull this syntax trick with data as a keyword though.

Re: Data Classes for Java

#127

Post by ScottBurson »

HumanDrivenDev wrote: post #2

... To write such a class responsibly, one has to write a lot of low-value, repetitive code: constructors, accessors ... If you're writing a plain data class, why on earth would you write getters and setters? Just make your fields public and be done with it. I will be forever perplexed by the idea of getters and setters (and this extends to C#s syntax sugar). I have no idea what problem they solve. If you're at the l…

Setters, at least, I find to be frequently useful places to put breakpoints when debugging. This is quite a bit rarer with getters, but I guess it happens occasionally.

Re: Data Classes for Java

#128

Post by hackits »

HumanDrivenDev wrote: post #122
hackits wrote: post #58

Earlier quoted context omitted.

`Technically` The current representation of `objects` in java is a abomination to the original idea behind object's. Hell even the use of class, members and fields fly in the face of what real objects are.

What do you mean by "real objects"? Are you refering to prototype OO?

Yes similar to a prototype language. The original design goals of OOP was you removed your constraints from the machine language and the restrictions that comes with a state based machine. Instead of focusing on mutex’s, member fields, private/public functions inheritance. You took your problem domain and deconstructed it using basic-level categorization into objects.

Those objects themselves would have behaviors and their own internal state. Those objects would communicate with each other via sending messages. It was up to the receiving object how it would or wouldn't reply to such a message. In this model there isn’t a type system as each object send messages to each other. To solve a distinct problem objects would delegate onto each other who would be the best to accomplish the task.

If you needed a object to have new behaviors you would just simply send a message to the object with the new routine/method/function. Just like the real world you could add/remove things from objects without any concern. In this way your objects morphed over time that where a representation of the complexity of the real world.

The problem that happened was a lot of OOP didn’t take place in the domain of the real world instead engineers moulded it to fit into a state based machine. Out went the notion of Objects sending messages to each other because it was too much of a performance hit. Out went the notion of clone objects instead replaced with a central management system such as classes. Next was the constrain of a type system, and inheritance.

The best example of a true OOP language today is javascript/small-talk/prototype languages.

Re: Data Classes for Java

#129

Post by wvenable »

HumanDrivenDev wrote: post #117
wvenable wrote: post #110

Earlier quoted context omitted.

Celcius is definitely a getter. The name absolutely implies that it's retrieving a value because it's name is not a verb or action. Properties in C#, for example, really just remove the ambiguity in this exact situation. Is it object.Celcius or object.Celcius()? A good C# programmer would use the former. A method would be object.RaiseTemp().

It looks like I have a really different definition of "getter" than some people here. I would only call something a getter if it explicitly makes reference and effectively exposes an internal field. Just giving a method a noun name is not enough to make it a getter, in my mind. It's the "get" prefix that says 'hey there is definitely a field in here called Foo that we think we're encapsulating but we're really not'.

Your definition of getter and setter are way too narrow. You exclude all getXX() and setXX() methods that don't directly manipulate a field and all C# property get/set the same way.

The getter or setter is part of the public interface of the object. The public interface makes no guarantees about implementation -- encapsulation is one of the fundamental principles of OOP. It is only supposed to appear from outside that you are getting/setting some internal property of the object. And that is the simplest implementation. However, the value of encapsulation is that it really doesn't have to implemented that way. Or the implementation could change entirely as long that public interface works the same way.

> I would only call something a getter if it explicitly makes reference and effectively exposes an internal field.

I think you're original question is "Why would anyone use a getter/setter if they could just a public field?" But your definition excludes all the reasons why someone would do it! If getters/setters just exposed internal fields and never anything else then they really serve no purpose.

Re: Data Classes for Java

#130

Post by aryehof »

HumanDrivenDev wrote: post #2

... To write such a class responsibly, one has to write a lot of low-value, repetitive code: constructors, accessors ... If you're writing a plain data class, why on earth would you write getters and setters? Just make your fields public and be done with it. I will be forever perplexed by the idea of getters and setters (and this extends to C#s syntax sugar). I have no idea what problem they solve. If you're at the l…

Frameworks elevated the need for getters and setters, given the need to programmatically access the internals of objects.

Their overuse is also a consequence of the popularity of a programming style of code acting on data, typically within an application that has class data merely representing database entities, acted on by separate logic and constraints in an application/service layer. Behavior based object design seems to be an endangered species.

Post reply on HN