Static fields in specialized classes

[Brian Goetz]

I could spend infinite hours answering questions like these and others, 
and it would be a very interesting discussion, but I think its a better 
use of our resources to focus on designing and building, so you'll 
forgive me if I don't answer all of these questions immediately.

But I'll just note that the @IdentityLess annotation notion is a decent 
mental model for what value types will be.  Take away identity, and you 
have to give up some things -- specifically mutability and polymorphism. 
  (C# went through some pretty big hoops to do mutable value types, 
which acquire the identity of whatever contained them, and later 
admitted that had been a pretty dumb thing to do.)  So the entire 
exercise for value types is essentially pulling on the string of "what 
does it mean to have aggregates without identity."

On 10/16/2014 2:13 AM, Daniel Latrémolière wrote:
>
>> In light of this, our conclusion is that the schism between values and
>> references is real, and what is needed is to treat it in a less ad-hoc
>> way, but not make attempts to hide it, since such attempts usually
>> fail (and when they do, the failures are even more painful.)
>
> When I see String/StringBuffer/StringBuilder or
> int/Integer/AtomicInteger, I am concerned by the number of needed
> schisms and the excessive use of similar but different absolute names
> for similar notions. Can you say which schisms are real in the
> characteristics of objects, like:
>
> - pass by reference or by value
> - has identity or not
> - mutability or not
> - thread-safety or not
> - possible others [1].
>
> Is it needed by schisms to use different absolute names or is type
> needing a definition by combining an unique absolute name, like
> java.lang.Integer with needed characteristics, using something similar
> to JSR 308. By example, can int be redesigned as a default shortcut of
> something like @IdentityLess Integer (but with annotation modifying
> behaviour, contrary to current annotations).
>
> [1]: In the following link, you can find some others possible generic
> characteristics of a type, like: nullness, interning, tainting, units, etc.
> http://types.cs.washington.edu/checker-framework/current/checker-framework-manual.html
>
>
> Thanks.
>