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