Value types questions & comments

[Ryan Schmitt]

>> This may be the reality-distortion field speaking, but in my view a

>> reference *is* a kind of value — albeit a very special kind.  They’re

>> immutable, like other values.  Almost all their state is encapsulated
(they

>> can be compared by identity, that’s it).  They can only be constructed by

>> privileged factories (we call these constructors.)  But, ultimately, they

>> behave like values — they are passed by value, they have no identity of

>> their own.

>>
> Well, FYI, this confuses and worries me.

This isn't a new concept. Anyone who has mutated a `final ArrayList` is
familiar with the concept of an immutable reference to mutable data. I
think the fundamental problem here, inherited from Java 1.0, is that there
is no language-level mechanism that can be used to distinguish immutable
objects like String from mutable objects like ArrayList, and so one of two
things has to happen in order to have useful default equals() and
hashCode() methods on value types:

(1) The language designers need to special-case certain legacy reference
types like String and Option in order to achieve the "deep equality"
behavior you expect to see by default
(2) The language designers need to retcon a mechanism for indicating such
types