Alternatives to Value Types?

[Krystal Mok]

Hi Ming-Yee,

The idea of annotation on a field for "embedding objects" or "colocating
objects" has cropped up once in a while.

A similar idea goes like:

class Foo {
  @Value private AtomicLong val = new AtomicLong(0); // "embed" the
AtomicLong in Foo
}

Anyway, I'd like to point out that the ObjectLayout [1] project actually
takes care of a concept similar to yours, but retains full object semantics.

- Kris

[1]: http://objectlayout.org/

On Tue, Jan 6, 2015 at 8:35 PM, Ming-Yee Iu <valhalla at jinq.org> wrote:

> Stephen Colbourne might have a point about these value types. Are there
> alternatives to value types that give fewer benefits but don't require such
> large Java changes?
>
> I'm sure you've considered it before and dismissed it, but maybe instead of
> value types, we could have value "fields"? I have no idea what I'm saying,
> but maybe instead of "No Identity" being an annotation on types, "No
> Identity" could be an annotation added to fields?
>
> class NoIdentityContainer<T> {
>   @NoIdentity_CopyByValue_HaveGoodLocality T field;
> }
>
> Creating an instance of the class will also create an instance of the T
> object with locality near to the container instance. Assigning to the field
> will actually result in a copy of the contents over the existing instance
> instead of just changing the pointer. Maybe the annotation could be applied
> to method parameters and return values as well. Objects stay as objects.
> Primitives stay as primitives. The only classes that have to deal with new
> "value" semantics are those classes that explicitly use the annotation.
> Things still break, but in a different way that might be more palatable.
>