Hacker News Reader

Comment by ashishb | Hacker News Reader

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.

View on HN

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.

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

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.

> 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?

I think they’re saying it doesn’t go far enough, but it was hard for me to parse the sentiment.

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.

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.

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.

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

not the object

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?

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.

Unless the object is immutable, like String, Integer, Long, ImmutableCollections, etc. Or your own immutable objects.

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

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.

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

Reply on news.ycombinator.com