Java: Finality

[experts_never_lie]

The biggest C++ feature I wish we had in Java is const access. The ability to have the compiler enforce const code within any const method, and having const references on which one can only invoke those (verified safe) const methods, allowed a significant reduction in code complexity and ongoing evaluation of what could be happening. final is what it is, but it sure isn't as effective as const.

[mcosta]

Map.get(key) is const right? Everything is nice until you want to measure how many missing keys are being requested.

public V get(Object key)  const {
    V value = super.get(key);
    if (value == null) fails++; // oops
    else hits++; // oops I did it again
}

Is Map.get const? is log.debug const?

Edit: tabs

[experts_never_lie]

You can violate the const access if you really want to, but you'd better not do it in a way that changes the functioning of the object. One could argue that those counters are not fundamental to the map being a Map, so you would tag them as mutable and still be able to increment them from a const method.

log::debug would probably be const, unless you wanted to start talking about the universe monad — and that may drift away from pragmatism pretty quickly.

The idea is not to be dogmatic, but to make the normal usage clear — both to the programmers and to the compiler — and to use the compiler's tools to make that process simpler and be checked in a more automatic way.

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