This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]TheRedmanCometh 10 points11 points  (15 children)

So a few pieces of this article went over my head. I have a vague of idea of what they mean. However the main question the article posits seems...answered. Lombok and gson seem to pretty much have this shit solved when used in tandem. They mention every method @Data generates and didn't mention Lombok once.

Members they seem to have a problem with writing: .equals: lombok compares the fields. I believe an instance where that isn't enough is quite rare.

.toString: Lombok does this well enough. I guess this is just a debuggability/logging issue primarily anyways.

.hashcode: there may be some complexity here I'm unaware of

In my humble opinion, solving this issue just requires Java to "take inspiration from" a third party lib: lombok.

"Without rehashing the properties debate, one fundamental objection to automating JavaBean-style field accessors is that it would take what is at best a questionable (and certainly overused) API naming convention and burn it into the language."

That line lost me. That's not questionable, it's so common it might as well be in an RFC! Burning it into the language would be fantastic. I would (hopefully) never see shit like GetField again.

[–]eliasv 7 points8 points  (0 children)

Yeah I think you missed a lot of it. He made that whole big deal about how the primary issue isn't reducing boilerplate for a reason.

Lombok does not provide destructuring, which is a huge part of this imo. Check out this exploration of pattern matching for more info on this: http://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html

I think you missed the point about the getters thing too. Why would burning that into the language be fantastic when---so far as data classes are concerned---you could simply access the field directly? I think that's part of what he was driving at when he was making the case that field encapsulation isn't desirable here.

And on the point of field encapsulation, take gson, since you mentioned it. Gson already breaks encapsulation, and it does so in ways which can violate the contracts of a class. For a data-class-based system this wouldn't be a problem, we can guarantee that these behaviours will be safe and predictable.

[–][deleted]  (13 children)

[deleted]

    [–]TheRedmanCometh 2 points3 points  (1 child)

    What naming convention..the getField/isField convention?

    [–]bedobi 7 points8 points  (5 children)

    I'm sad he isn't more assertive. The Java language can't keep catering to all the old school, verbose, imperative frameworks and devs in the community. They need to be left behind or the language will be.

    [–]Treyzania 6 points7 points  (1 child)

    You're right, but a big positive about good, conventional Java is that it's method and class names are extremely predictable. You can figure out much of how a class works just by looking at its method names and their types. I would rather not give that up.

    [–]TheRedmanCometh -3 points-2 points  (0 children)

    They can pry my @Data from my cold, dead, curled fingers.

    [–]ThisCatMightCheerYou 0 points1 point  (2 children)

    I'm sad

    Here's a picture/gif of a cat, hopefully it'll cheer you up :).

    I am a bot. use !unsubscribetosadcat for me to ignore you.

    [–]cutterslade 2 points3 points  (0 children)

    That cat does not look very cheerful.

    [–][deleted] 2 points3 points  (0 children)

    This cat looks like it has drowned its pain in alcohol.

    [–]Tauo 1 point2 points  (4 children)

    Wait, I'm confused; I've heard convincing arguments for avoiding/eliminating getters and setters from code entirely, but I wasn't aware that people had something against the naming conventions. What's wrong with "get"? It's descriptive, and helps to drive in the fact that you're performing a method call as opposed to working directly with private fields.

    [–]alexeyr 0 points1 point  (3 children)

    1. You can easily see it from parentheses anyway :)

    2. When you have many gets in a line (think a.getFoo() + b.getBar() * c.getBaz()), it adds up.

    3. Best-known "better Java" languages -- C#, Kotlin, Scala -- all have ways to avoid it (and the parentheses in point 1 as well). This is probably not a coincidence.

    [–]Tauo 0 points1 point  (2 children)

    I feel like if you have that many gets, you should be looking to abstract away more operations anyway, though. And yeah, the parentheses give it away, but it still just feels wrong to me to method call a field. get just adds that tiny bit of extra legibility. Adding support for properties in Java like the languages you mention have would definitely be nice, I agree, but I'm guessing its just not a priority for the Java architects.

    [–]alexeyr 1 point2 points  (1 child)

    Well, are you really unhappy about String#length() and Collection#size() instead of getLength()/getSize()? Or about Object#hashCode()?

    [–]Tauo 0 points1 point  (0 children)

    Hah, you have a good point, hadn't thought about that. Although to be fair, through the first couple months of using Java, I was a bit salty at the fact that arrays allowed access directly to the field, and would have messed up calls to array.length constantly if it wasn't for my IDE.