undefined | Better HN

0 pointscbsmith3y ago0 comments

> When I write code, it's common to have references to immutable classes thrown around with wild abandon, heedless of ownership, threads, or good taste, because the data just can't change.

If there's anything I wish languages with implicit reference semantics would adopt, it's implicit immutability. I wish Java would be so much nicer with keyword that is half way between "final" and "volatile" that means, "yes, you can actually mutate this" and then make final semantics the default for fields & variables.

0 comments

cogman103y ago

Agreed.

Could you Imagine a Java where you have a `Map` and a `MutableMap` and that's what you put at your API? I'd make it SO much clearer how safe any individual API is to call.

spockz3y ago

Scala has had this for ages. You can have it today. Even in Java either through the Google collection library or through a library that mimics fp style programming. The name eludes me for the moment.

gowld3y ago

Guava, but it's not fully typesafe.

Mutable is not part of the Java meta-language used for typing.

ImmutableMap implements Map

https://guava.dev/releases/23.0/api/docs/com/google/common/c...

and throws exceptions on mutation.

https://guava.dev/releases/23.0/api/docs/src-html/com/google...

morelisp3y ago

In general this doesn't work, the history rule says mutable types are not proper subtypes of immutable ones (and the converse is obvious). If you want to capture mutability in your type system, it needs to be orthogonal to subtyping (like C/C++ const).

a_t483y ago

C++ still has this problem - std::unordered_map<std::string, std::string>` and `std::unordered_map<std::string, const std::string>` are basically unrelated types - you can't const-cast the templated const away. (I may be misunderstanding here)

1 more reply

cogman103y ago

> the history rule

I'm unfamiliar with this rule (and not finding anything good to google). Can you elaborate?

I can't really think of a scenario where an immutable datastructure isn't a subset of actions against a mutable datastructure.

1 more reply

gowld3y ago

Not quite.

Conceptually, you can have constness in your subtype-system (as long as you are sticking with interfaces (methods), as Liskov's subtyping model does, and aren't inherting potentially-mutable fields).

MutableMap and ImmutableMap are both subtypes of a hypothetical ReadableMap. ImmutableMap is the same as ReadableMap, but has an informal contract that subclasses shouldn't add mutability.

foverzar3y ago

Kotlin has this

thomascgalvin3y ago

Kotlin has this, but the Map is (usually) a MutableMap under the covers, because it's Java bytecode at the lower levels. You have to go out of your way to footgun yourself, but it's still possible.

j / k navigate · click thread line to collapse

0 comments

cogman103y ago

Agreed.

Could you Imagine a Java where you have a `Map` and a `MutableMap` and that's what you put at your API? I'd make it SO much clearer how safe any individual API is to call.

spockz3y ago

Scala has had this for ages. You can have it today. Even in Java either through the Google collection library or through a library that mimics fp style programming. The name eludes me for the moment.

gowld3y ago

Guava, but it's not fully typesafe.

Mutable is not part of the Java meta-language used for typing.

ImmutableMap implements Map

https://guava.dev/releases/23.0/api/docs/com/google/common/c...

and throws exceptions on mutation.

https://guava.dev/releases/23.0/api/docs/src-html/com/google...

morelisp3y ago

a_t483y ago

1 more reply

cogman103y ago

> the history rule

I'm unfamiliar with this rule (and not finding anything good to google). Can you elaborate?

I can't really think of a scenario where an immutable datastructure isn't a subset of actions against a mutable datastructure.

1 more reply

gowld3y ago

Not quite.

Conceptually, you can have constness in your subtype-system (as long as you are sticking with interfaces (methods), as Liskov's subtyping model does, and aren't inherting potentially-mutable fields).

MutableMap and ImmutableMap are both subtypes of a hypothetical ReadableMap. ImmutableMap is the same as ReadableMap, but has an informal contract that subclasses shouldn't add mutability.

foverzar3y ago

Kotlin has this

thomascgalvin3y ago

Kotlin has this, but the Map is (usually) a MutableMap under the covers, because it's Java bytecode at the lower levels. You have to go out of your way to footgun yourself, but it's still possible.

j / k navigate · click thread line to collapse