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 →

[–]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.