Aggressive unboxing of values: status update

[Victor Nazarov]

I don't know where to leave suggestions. But I'd like to state some of my
ideas as I haven't heard something like this considered for implementation
of value types. I don't advocate any of this as one true way. I just want
to provide some input during exploration phase until it is to late.

1) Maybe it's time to make value types not equalTestable and not
toStringable. As I understand value-types are not required to inherit from
Object. I think It should be considered an option to refactor Object class
into one explicitly implementing set of default interfaces:

class Object implements EqualTestable<Object>, ToStringable, Hashable {
}

interface EqaulTestable<any T> {
    boolean equals(T other);
}

interface ToStringable {
    String toString();
}

interface Hashable {
    int hashCode();
}

Value-types are not required to implement any of these. They should choose
what interfaces makes sense for each distinct type. And compiler should
mark illegal calls to these interfaces. Classes can explicitly state
requirements for type variables like:

class HashMap<any K extends Hashable & EqaulTestable<? super K>, any V> {
... }

2) Add conditional interface implementations. It's already on agenda to add
specializations and specializated methods. I hope that Java can provide
more structured and more powerfull specializations.

Current proposal is something like

interface List<any T> {
  T removeAt(int index);
  void remove(T value);

  <when ref T>
  default T remove(int index) {
    return removeAt(index);
  }
}

I'd like to add some structure to specializations. Instead of bare
conditional method declarations I'd like to have conditional interface
implementations

interface ObjectList<ref T> {
  T remove(int index)
}

interface List<any T> extends <when ref T> ObjectList<T> {
  T removeAt(int index);

  <when implements ObjectList>
  default T removeAt(int index) {
     return remove(index);
  }

  void remove(T value);
}

Many interfaces can be additionally refined to provide more convenience
methods with such conditional interface implementations

interface ComparableList<T> {
  T max();
  T min();
}

List<any T> extends <when T extends Comparable<? super T>>
ComparableList<T> {
   <when implements ComparableList>
   T max() {
     ...
   }

   <when implements ComparableList>
   T min() {
     ...
   }
}


Victor Nazarov

On Tue, Nov 11, 2014 at 11:10 AM, Brian Goetz <brian.goetz at oracle.com>
wrote:

> >> There is nothing wrong with having boxes. One part of the development
> plan is to implement a boxing operation. Did you have a look at the "Boxing
> and object interoperability" section of this document?
> >>
> >> http://cr.openjdk.java.net/~jrose/values/values-0.html
> > Yes, I'm aware of that. It's just not very helpful, because most
> interesting cases and issues are not covered.
>
> That’s because we’re just getting started!  We don’t know the answers to
> all the questions yet.  Please be patient.
>
> >
> > I'm questioning the idea of
> >   a) having Integer act as a value box for int,
>
> You should be questioning this — it’s questionable.
>
> >   b) putting all the same requirements on value boxes;
>
> > from my experience, trying to retrofit Integer as a value box for int is
> a futile endeavor, as well as weighing down other value boxes with things
> like reference equality etc. in the way John described in his mail.
>
> It is quite likely that Integer will not be suitable as a box for int when
> all is said and done; we’re trying to be open minded and not disqualify
> prematurely.
>
>
>