4 ms·

"finally" in Java and afaik "val" in Kotlin because of it are a bit of a sham: They work fine for primitives, but for reference types only apply to the object i

"finally" in Java and afaik "val" in Kotlin because of it are a bit of a sham: They work fine for primitives, but for reference types only apply to the object identity. You can still mutate the pointed-to object willy-nilly.

oweiler 4y ago
It means non-reassignable, nothing more.
vbezhenar 4y ago
The way this is solved in modern code is that you very rarely have mutable objects. So basically you can expect all objects to be immutable (excluding obvious exceptions like builder objects). Some frameworks like JPA are not up-to-date with this methodology, sadly. But Java direction with immutable records is obvious and they'll adapt.
sischoel 4y ago
Isn't that the case for most programming languages? The only exceptions I can think of are C++ and Rust.
- arrow7000 4y ago
  It's not like this in the functional languages I'm familiar with, F# and Elm
  - kaba0 4y ago
    It is not like this in Java either if the components are all immutable as well. It will be shallowly immutable, but applying it recursively will make it totally immutable. The reason I say that is that in practice it is not that different than FP languages, they just differ in the ratio of FP data structures.
- Sankozi 4y ago
  const in C++ is more like Readonly from TypeScript - you cannot modify state of an object, but it still might be possible through other reference/pointer - you have to check source of that value to be sure
stefs 4y ago
i guess interior mutability just a design decision - it's not a _sham_, it works as intended. i'd like to know the reasons for this.
- kaba0 4y ago
  I’m not sure this is the reason, but OOP is supposed to handle encapsulation of state. For example lazy initialization of an object can be done by proper encapsulation and interior mutability, while the outside view can be completely immutable.
- imtringued 4y ago
  Because that is how final works in Java.

oweiler 4y ago

It means non-reassignable, nothing more.

vbezhenar 4y ago

The way this is solved in modern code is that you very rarely have mutable objects. So basically you can expect all objects to be immutable (excluding obvious exceptions like builder objects). Some frameworks like JPA are not up-to-date with this methodology, sadly. But Java direction with immutable records is obvious and they'll adapt.

sischoel 4y ago

Isn't that the case for most programming languages? The only exceptions I can think of are C++ and Rust.

arrow7000 4y ago
It's not like this in the functional languages I'm familiar with, F# and Elm
- kaba0 4y ago
  It is not like this in Java either if the components are all immutable as well. It will be shallowly immutable, but applying it recursively will make it totally immutable. The reason I say that is that in practice it is not that different than FP languages, they just differ in the ratio of FP data structures.
Sankozi 4y ago
const in C++ is more like Readonly from TypeScript - you cannot modify state of an object, but it still might be possible through other reference/pointer - you have to check source of that value to be sure

stefs 4y ago

i guess interior mutability just a design decision - it's not a _sham_, it works as intended. i'd like to know the reasons for this.

kaba0 4y ago
I’m not sure this is the reason, but OOP is supposed to handle encapsulation of state. For example lazy initialization of an object can be done by proper encapsulation and interior mutability, while the outside view can be completely immutable.
imtringued 4y ago
Because that is how final works in Java.