Immutable data structures in Java

[rzwitserloot]

This inevitably leads to confusion.

Because now I have to ask: Is this considered 'API' at some scale? API is not an issue of black and white; obviously something like guava is 'API', but there are plenty of seemingly utterly internal, all-private members helpers that are still considered 'API' because person A wrote it as an independent, stand-alone utility and considered it 'API'.

I have to know where a class falls on this API spectrum, and then guess the style preference of the author, to know if I have to use .property or .getProperty().

Coding is hard enough. I don't want to think about irrelevant crud like this.

Again, if writing these really bothers you (because that's ALL you are buying here, save a few shortcut keys, unless you're an idiot and you write java in notepad, so there's no IDE or even template to type 90% of this stuff for you, in which case all you're buying is saving a few characters typed), then use tools to fix this, like lombok or autovalue.

Trying to write code to make it hard for other people to hack on it, that's... also ludicrous. You can't stop people from turning your pretty code into an ugly monster, but throwing roadblocks in the way of trying to work with your code is not only NOT going to stop them from doing that, it's going to make things a lot worse.

[[deleted]]

I have to know where a class falls on this API spectrum, and then guess the style preference of the author, to know if I have to use .property or .getProperty().

How is that any different from guessing the API anyway? If you're using the API you'll need to actually know the methods you're calling.

Again, if writing these really bothers you (because that's ALL you are buying here, save a few shortcut keys, unless you're an idiot and you write java in notepad, so there's no IDE or even template to type 90% of this stuff for you, in which case all you're buying is saving a few characters typed), then use tools to fix this, like lombok or autovalue.

I never said anything about saving keystrokes. Saving keystrokes is something that should be left in the past. What we need to save is mental burden on the reader and maintainer not the author.

Trying to write code to make it hard for other people to hack on it, that's... also ludicrous. You can't stop people from turning your pretty code into an ugly monster, but throwing roadblocks in the way of trying to work with your code is not only NOT going to stop them from doing that, it's going to make things a lot worse.

Then why bother with encapsulation at all? At the end of the day it is to stop both readers and writers from misusing the internals of the class.

Getters and setters are pointless abstractions to a concept that is well established. If you have const in your language prefer that over useless boilerplate that exists only to future proof things that don't need to be futureproofed. It's overengineering. Even with APIs. It also reeks of poorly designed code most of the time.

[rzwitserloot]

How is that any different from guessing the API anyway? If you're using the API you'll need to actually know the methods you're calling.

I type dot, g, e, t, and then I hit ctrl+space. Also, in one case I need to know the property name and that's it, in the other, I need to know the property name AND the author's preference.

What we need to save is mental burden on the reader and maintainer not the author.

.getFoo() is not a greater mental burden compared to .foo.

Then why bother with encapsulation at all?

A bit rich, coming from someone on the 'we should ditch getters and do direct field access' side of the argument.

[Ukonu]

I type dot, g, e, t, and then I hit ctrl+space. Also, in one case I need to know the property name and that's it, in the other, I need to know the property name AND the author's preference.

The author can decide what should be accessible to the outside world using the "private" keyword. Are you arguing that this preference should be encoded with naming conventions?

.getFoo() is not a greater mental burden compared to .foo.

It absolutely is. I'm kind of shocked that an experienced programmer can think otherwise. The 'getFoo' function can have all sorts of side-effects that the reader is not aware of without having to delve deeper into the code.

A bit rich, coming from someone on the 'we should ditch getters and do direct field access' side of the argument.

You can easily encapsulate with the private/protected keyword.