State of the Values

[Roel Spilker]

Hi all,

Good to see this amount of progress already!

1) Is there already a separate mailing list, like for lambdas, for
discussing value types?

I have some questions/suggestions:

2) In the section  "Life without pointers", is states "Null is a valid
value of every reference type, meaning “no instance”. But assignment to,
and comparison to, null for value types should be disallowed. This
restriction does not apply to the boxed form of a value type." I agree with
the idea. But a value can contain references. In some (hopefully rare)
cases it's useful to null those. Having a way to "clear" a value would be
helpful. Maybe the "empty" value should be part of the generated code:
Point.empty(). The developer of the type can provide it, or the user can
make his own EMPTY "instance". But since it's necessary for initialization,
it might be worth wile investigating if it can become part of the generated
code.


3) For evolution purposes, wouldn't it be possible to always use getter
methods and allow the field access syntax for accessing the values. That
way, public "fields" can later be emulated by providing a getter method.
Possibly those methods should marked as getter and not be based on naming
patterns.

So
value class Point {
   public final int x, y;
}

would become

value class Point {
  private final int x, y;

  __Getter public int getX() {return this.x;}
  __Getter public int getY() {return this.y;}
}

class Dot {
  void renderAt(Point p) {
    drawDot(p.x, p.y) // getter invocation for value types
  }
}


4) By providing (optionally) generated "with"-methods instead of allowing
mutable fields and setters, it could be possible to have a lightweight way
to modify a single "field"

value class Point {
    public int x, y;

    public Point withX(int newX) {
        if (this.x == newX) return this;
        return new Point(newX, this.y);
    }
}

- The users of such a method would understand that they would get a "copy"
and not be modifying an existing instance
- Escape analysis could often replace this by a single register update p =
p.withX(p.x + 1);




On Mon, May 5, 2014 at 6:37 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> We’ve asked that question ourselves.  Its a definite “maybe”.
>
> Answering such questions is a long ways off; our primary focus for the
> time being is the VM-level semantics; the language semantics come later,
> and later still “syntaxy” issues like this.
>
> On May 4, 2014, at 12:15 PM, Ulf Zibis <Ulf.Zibis at CoSoCo.de> wrote:
>
> > I think, this is a great proposal.
> >
> > > Value/primitive convergence. Can we integrate primitives into the
> values family?
> > > __ByValue class int { ... }? Can we get to a world where primitives
> are just predefined value types?
> >
> > Does that mean that we could invoke e.g. methods of class Integer on
> primitive int type?
> >    int a = 5;
> >    String aAsString = a.toString();
> >    String seven = 7.toString();
> >
> > That I would like very much!
> >
> > -Ulf
> >
> >
> > Am 04.05.2014 04:07, schrieb Paul Benedict:
> >> For anyone interested, here's a new article on perhaps forthcoming value
> >> types:
> >>
> >> http://cr.openjdk.java.net/~jrose/values/values-0.html
> >>
> >> Cheers,
> >> Paul
> >>
> >>
> >
> >
>
>
>