more background to List<int> specializing List<Any>

[Thomas W]

Thanks, this is very interesting. And I see that choosing the "functional
interface" route for Java 8, has actually worked much better than starting
to pull on that "functional types" string, which would have brought
_everything_ into the typesystem!

At the moment, I'm interested in the questions around top of the type
heirarchy -- List<any>, List<? extends Object>, List<int> typing.

I'm very happy with List<Object>, as a practical implementation strategy
for List<T extends any> when T is a reftype. But I'm not sure how or
whether this can address the inheritance problems Gavin was referring to.
I'd like to look into that further.

[I'm also interested in Any vs Object since my day jobs are involved in
framework & persistence architecture, and I have a general interest in
car-crash stories :-)]

And on the other side of the coin, if we did have an "abnormal" inheritance
situation it might be better to just acknowledge that honestly in syntax,
so nobody need be confused.

    new ArrayList<Object>
    new specialized ArrayList<int>     // actually creates a derivative
class

Tossing up longer syntax, versus explicit acknowledgement of a shiny new
performance feature & it's different behavior.


Regards,
Thomas


On Mon, Jan 5, 2015 at 7:40 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> I know our focus in this current phase is on "Layers", but would like to
>> educate myself further about the general background of issues with Any.
>>
>
> Let me correct slightly.  We're investigating "layers" or "conditional
> methods" not because this is the feature we went looking for, but because
> it is a possible and believed-practical answer to the more general question
> of "what generic type system can provide us the gradual migration
> compatibility we are looking for."
>
> This is not unlike what happened in 8; we didn't do default methods
> because we wanted multiple inheritance of behavior; we did it because we
> needed *interface evolution*, and of the dozen or so possible ways to get
> there that we evaluated, this one had the best combination of
> characteristics.
>
> So far we've gotten feedback that people don't like the balance of "user
> model weight" and "general utility" for layers (feedback received loud and
> clear, no need to reopen this.)
>
>
> More generally, I think there's a lot of tendency to assume here that
> these writeups constitute *decisions*, which they do not.  These writeups
> are snapshots of where our head is at this week, which we provide so people
> can get a peek about what we're thinking about.  But we're a long way from
> the end of this road.
>
>