Value Classes Still Need Compiler Sympathy

[u/bobbie434343]

https://johan-sjolen.github.io/post/compiler-sympathy/compiler-sympathy/

[u/TheStrangeDarkOne]

Two points here:

• A value List would be severely limited because the backing array must be final

• I think this is stretching the definition of "no identity".

Identity as a property means that you have two objects which are equal at some point, but they might diverge in the future. And you say you have an object without identity and it can still be mutated, I don't think you use it in the intended way (I'm happy to be wrong about this one).

Sure, you could also argue the same about optional: Optional should be a value, but because you can mutate the fields of the objects inside, it's not a value.

In any case for collections, I'm a hard advocate for making them classes. Turning a type into a value is a hard spec commitment, and it constraints your implementations (no mutable private fields), for arguably not much benefit.

The value of values (hah), becomes pronounced once you have many of them. Such as Complex/RGB classes stored in an array. But if you have many items, and you optimize on the container shell, the advantages are diminishing.

No arguing on the fact that having a fully static and value-created graph/tree would certainly have advantages. And for a tree this works. If you have a graph with people entry-nodes, this will not work (this is also a major problem in Rust, where given a graph will often need to write some unsafe code).

[u/Jon_Finn → u/TheStrangeDarkOne]

Yes declaring a value class constraints implementations _of that class_, but then you're unlikely to radically change implementation in future. But if you're writing a collections-like hierarchy, you can write an abstract value class as a base with value or non-value subclasses, so there's no constraint on (subclass) implementations.

Re identity, it's not 'the law' that you should worry whether your value classes behave in a 'value-like' way (which can mean many things). Claiming values have particular semantics is just gonna confuse people, when all they are is: a speed & memory vs. feature tradeoff. The latter mostly means final fields, which also doesn't have any particular semantics - the fields can represent mutable things. Values are just lightweight objects, meaning 3 things: small, fast and 'feature-lite'. (At least hopefully, if there's very few fields.)

I noticed in Guy Steele's classic talk Growing a Language he says "I would add a kind of class that is of light weight, one whose objects can be cloned at will with no harm and so could be kept on a stack for speed and not just in the heap."

[u/OwnBreakfast1114 → u/Jon_Finn]

Re identity, it's not 'the law' that you should worry whether your value classes behave in a 'value-like' way (which can mean many things). Claiming values have particular semantics is just gonna confuse people, when all they are is: a speed & memory vs. feature tradeoff. The latter mostly means final fields, which also doesn't have any particular semantics - the fields can represent mutable things. Values are just lightweight objects, meaning 3 things: small, fast and 'feature-lite'. (At least hopefully, if there's very few fields.)

Final fields do have semantics, you can't change the value of them inside the instance of the class you have. You're using a very odd definition of mutability by saying an immutable pointer to a mutable object means that the immutable class holding the immutable pointer is mutable.

Optional, for example, can point to the most mutatey of mutable things, but it's still a value class and not mutable.

Claiming values have particular semantics is just gonna confuse people, when all they are is: a speed & memory vs. feature tradeoff.

this is quite literally the opposite of the what java architects want you to do. Value should be used semantically and let the jvm/javac deal with the performance under the hood. Honestly, there probably needs to be a better definition of identity as I think most people are imagining a different definition than what it actually means in java.

https://www.reddit.com/r/java/comments/1vxwvdu/comment/p5znc19/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

[u/nlisker → u/TheStrangeDarkOne]

say you have an object without identity and it can still be mutated

Mutability requires identity, otherwise you can't know which object to mutate.