4 ms·

I wish we can have immutable runtime objects (e.g. final in Java or const in C++). Go has constant (`const`) type that can be evaluated at compile-time but no

I wish we can have immutable runtime objects (e.g. final in Java or const in C++). Go has constant (`const`) type that can be evaluated at compile-time but no const type for something that can only be evaluated at Run time.

blibble 2y ago
final in java only makes the primitive (or reference) immutable not the object
- ashishb 2y ago
  Class Rect { final int x, y; //Constructor goes here } Rect r1 = new Rect(1,2); Is this not sufficient to create an immutable rectangle that I can pass around safely in a multi-threaded code?
  - maleldil 2y ago
    When x and y are primitives, yes. But if they're objects, final only prevents you from re-assigning them. You could still call methods that mutate them.
    - loginatnine 2y ago
      Unless the object is immutable, like String, Integer, Long, ImmutableCollections, etc. Or your own immutable objects.
      - ashishb 2y ago
        > Unless the object is immutable, like String, Integer, Long, ImmutableCollections, etc. Or your own immutable objects. Exactly. You can have immutable primitives. You can have immutable classes. And you can combine them to form thread-safe immutable classes.
        maleldil 2y ago
        Now you're restricting yourself to a subset of the language. There's nothing stopping someone from adding a mutable member to your "immutable" type later. It's much better to have immutable bindings/references so that nothing that mutates the object can be done through them. Rust does it very well, for example. Even C++ has a good version of this.
        ashishb 2y ago
        > It's much better to have immutable bindings/references so that nothing that mutates the object can be done through them. Rust does it very well, for example. Even C++ has a good version of this. Yes, that might be superior but even Java is doing better than Go here.
pie_flavor 2y ago
Non-deeply-immutable reference fields are a joke and solve no problems. They don't save you from needing to make defensive copies to stop shared mutation, and everything else is a padlock on your left pocket to stop your right hand reaching in.
- jcelerier 2y ago
  I can't count how many times adding `const` in c++ saved me from myself, I do t understand why you would ever not want it. You even say it: "padlock on your left pocket to stop your right hand reaching in" Do you trust yourself to write perfect code 100% of the time ? No? Then padlock it is
  - stouset 2y ago
    I think they’re saying it doesn’t go far enough, but it was hard for me to parse the sentiment.
  - Olreich 2y ago
    Const only saves you most of the time if you have a “const” all the way down the type structure. If I have a type Foo with a field that is a pointer to a mutable value, instantiating a Const Foo just means I’m always pointing at the same mutable value, not that I have an unchangeable Foo. Const support in languages never makes all modifications to data accessed through the variable locked out, just the top level, which makes it much more difficult to ensure that the assumptions about immutability hold without constantly doing deep copies or having to double and triple check that your Const definitions are correct. Const often leads to a false sense of security.
    - jcelerier 2y ago
      > If I have a type Foo with a field that is a pointer to a mutable value, instantiating a Const Foo just means I’m always pointing at the same mutable value, not that I have an unchangeable Foo. yes and that's fine ? for instance how would you encode a graph operation where you want the graph structure to be immutable and the content of the nodes to be variable?
drdaeman 2y ago
I'm afraid that'll only result in some people using those inappropriately then other people using `reflect` to mutate those objects. Just like with "private" methods and fields when library authors create a good library but don't expose something crucial for anther person's task at hand.
- XorNot 2y ago
  Man I can't remember whichever black magic I invoked to bust into some C# sealed classes for some office application. But I was glad it existed because it enabled a whole set of valuable business automation at the time.
- School-Cotton 2y ago
  Nothing in any programming language I’m aware of prevents you from opening /proc/<pid>/mem and changing the state arbitrarily. I don’t think we should avoid adding features to programming languages because a malicious coworker might work around them.

blibble 2y ago

final in java only makes the primitive (or reference) immutable not the object

ashishb 2y ago
Class Rect { final int x, y; //Constructor goes here } Rect r1 = new Rect(1,2); Is this not sufficient to create an immutable rectangle that I can pass around safely in a multi-threaded code?
- maleldil 2y ago
  When x and y are primitives, yes. But if they're objects, final only prevents you from re-assigning them. You could still call methods that mutate them.
  - loginatnine 2y ago
    Unless the object is immutable, like String, Integer, Long, ImmutableCollections, etc. Or your own immutable objects.
    - ashishb 2y ago
      > Unless the object is immutable, like String, Integer, Long, ImmutableCollections, etc. Or your own immutable objects. Exactly. You can have immutable primitives. You can have immutable classes. And you can combine them to form thread-safe immutable classes.
      - maleldil 2y ago
        Now you're restricting yourself to a subset of the language. There's nothing stopping someone from adding a mutable member to your "immutable" type later. It's much better to have immutable bindings/references so that nothing that mutates the object can be done through them. Rust does it very well, for example. Even C++ has a good version of this.
        ashishb 2y ago
        > It's much better to have immutable bindings/references so that nothing that mutates the object can be done through them. Rust does it very well, for example. Even C++ has a good version of this. Yes, that might be superior but even Java is doing better than Go here.

pie_flavor 2y ago

Non-deeply-immutable reference fields are a joke and solve no problems. They don't save you from needing to make defensive copies to stop shared mutation, and everything else is a padlock on your left pocket to stop your right hand reaching in.

jcelerier 2y ago
I can't count how many times adding `const` in c++ saved me from myself, I do t understand why you would ever not want it. You even say it: "padlock on your left pocket to stop your right hand reaching in" Do you trust yourself to write perfect code 100% of the time ? No? Then padlock it is
- stouset 2y ago
  I think they’re saying it doesn’t go far enough, but it was hard for me to parse the sentiment.
- Olreich 2y ago
  Const only saves you most of the time if you have a “const” all the way down the type structure. If I have a type Foo with a field that is a pointer to a mutable value, instantiating a Const Foo just means I’m always pointing at the same mutable value, not that I have an unchangeable Foo. Const support in languages never makes all modifications to data accessed through the variable locked out, just the top level, which makes it much more difficult to ensure that the assumptions about immutability hold without constantly doing deep copies or having to double and triple check that your Const definitions are correct. Const often leads to a false sense of security.
  - jcelerier 2y ago
    > If I have a type Foo with a field that is a pointer to a mutable value, instantiating a Const Foo just means I’m always pointing at the same mutable value, not that I have an unchangeable Foo. yes and that's fine ? for instance how would you encode a graph operation where you want the graph structure to be immutable and the content of the nodes to be variable?

drdaeman 2y ago

I'm afraid that'll only result in some people using those inappropriately then other people using `reflect` to mutate those objects. Just like with "private" methods and fields when library authors create a good library but don't expose something crucial for anther person's task at hand.

XorNot 2y ago
Man I can't remember whichever black magic I invoked to bust into some C# sealed classes for some office application. But I was glad it existed because it enabled a whole set of valuable business automation at the time.
School-Cotton 2y ago
Nothing in any programming language I’m aware of prevents you from opening /proc/<pid>/mem and changing the state arbitrarily. I don’t think we should avoid adding features to programming languages because a malicious coworker might work around them.