Value-Based Classes - equals/hashCode

Peter Levart peter.levart at gmail.com
Sat Feb 14 23:46:33 UTC 2015


On 02/14/2015 10:03 PM, Brian Goetz wrote:
> Here's a stab at thinking about this, which I'm sure is wrong, but 
> might be a helpful start.  Say a value-ish class C has fields 
> c_1..c_n. Now let's try and define S(C), the variables that comprise 
> the "state" of C.  S(C) includes:
>  - \forall_i c_i, if c_i is a primitive
>  - \forall_i S(c_i), if c_i is a reference to a value-ish class
>  - \forall_i c_i, if c_i is a reference to a non-value-ish class
>
> In other words, if a value contains other values, we recursively 
> include the dependent value in the state; if a value contains 
> references to non-values, we can only include the that reference 
> (references are values!), but not any state reachable through that 
> reference.  (We wave our hands and magically define certain 
> otherwise-problematic classes (like String) to be value-ish.) 

Here's another constraint for value-ish classes: they must not form 
circles composed from only value-ish objects in object graphs.

Peter




More information about the valhalla-dev mailing list