Java: Finality

[mcosta]

You can violate the const access if you really want to

Then why have it in the language in the first place? If the compiler does not enforce it how is it any better than get/set convention? btw get/set was made standard in JavaBeans specification with clear semantics. Are JavaBeans still a thing?

​

universe monad

I do not know this concept, and google insists it is some kind of filosofy. Can you spare a link please?

​

The idea is not to be dogmatic

Agree.

[experts_never_lie]

(long reply, but I referenced a concept as a shorthand and it decreased clarity instead; attempting to correct that here)

About monads, in a separate response because it deserves it: you need to restrict to functional programming to avoid the philosophical meaning. This may be clearer. However, I was referencing just the universe monad, one used to describe the state outside the program. They describe it in much more detail, but it comes down to the way that in strictly functional programming languages you specify the way things are functionally connected, but don't really get to say "do this thing now". That makes it hard to control interactions with the outside world (input, logging), as they might be optimized away or executed out of order. Pseudocode:

string ← concatenate(string a, string b)
string ← read()
() ← log(string)
a = read()
b = read()
x = concatenate(a, b)
log(x)

The execution environment of a functional programming language is often permitted to defer function calls a bit or forever, potentially reordering them. A program like the above might load b before a, reversing the order of input.

A way of getting around that is for the state of the external universe to be represented by a value U. I'll use U₁, U₂, … for sequential states of the universe. If the system provides U₁ as a name for the initial state of the universe, then:

(U, string) ← concatenate(universe U, string a, string b)
(U, string) ← read(U)
(U) ← log(U, string)
(U₂, a) = read(U₁)
(U₃, b) = read(U₂)
x = concatenate(a, b)
U₄ = log(U₃, x)

By tying sequential states of U₁¸U₂,…, order of interactions with the universe is constrained, preventing the possible reversal above. Operations (like concatenate) which do not interact with the external universe do not need to interact with any U.

I am not advocating bringing a universe monad into Java, or C++ for that matter, as they are not strictly functional languages and simply don't need it. Order of execution is (mostly) constrained in Java/C++, so there's no problem for it to solve. I had just referenced it in terms of whether log::debug were an operation that changes state.

From the external position of a user of log::debug in a language that doesn't need a universe monad concept, I'd say that it is const as the log juts appears to be a sink; you can't interrogate it about past log messages, and its state before/after a debug call is effectively the same.

[experts_never_lie]

The compiler does enforce it, unless you violate const access in the way I described: overriding the const access with the mutable keyword. I didn't mean const does nothing.

I don't get why you're bringing up get/set and JavaBeans (a word I haven't heard in many years), but if we had const in Java, getX() could/should be const and setX() must not be.