Fwd: Proposal for generics over primitives needs a rethink

[Gavin King]

On Wed, Dec 31, 2014 at 11:33 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> For the record, the reason we rejected a unified 'Any' type is: it is a
> fiction.

So this sentence has been bothering me for a day or so, and after
reflection, I think there's three reasons why it's a very bad way to
frame the problem.

First: if Any is a "fiction" in this sense, then all of Java generics
is also a fiction. It's therefore not surprising that, in thinking
about how to enhance a "fictional" facility, that other "fictional"
constructs would also arise.

Second: but in fact it's perfectly normal to have constructs that are
"fictional" in this sense. What Any means at the level of the bytecode
and virtual machine is something that is completely abstracted by the
Java language and almost always irrelevant to the programmer. A Java
programmer doesn't write or read bytecode and 98% of Java developers
never even look at it. There's only one way in which it could become
relevant, and that's if Any entailed an unacceptable loss of
performance, which, as I've argued in my previous email, it does not,
at least as far as I can see.

Third: if it's truly unacceptable for Any to be "fictional" in this
sense, which I think is clearly not the case, then there's an obvious
solution as both Rémi and I have pointed out: implement an Any type in
the JVM as a discriminated union. And indeed, once you start looking
closely, it seems to me that this might be the best option of all.
With Any in the JVM, then perhaps (of course I've not thought through
all the details) all the whole "specialization" machinery - which I
think we can agree is somewhat ugly - might be completely unnecessary!

Therefore I arrive at two conclusions:

- A "fictional" Any is perfectly defensible. It doesn't preclude an
implementation based on specialization, AFAICS, and it's not
problematic in any way in which Java generics aren't already
problematic.

- On the other hand, thinking about Any leads us to consider a
different possible implementation that doesn't depend on
"specialization", which makes the VM more flexible and more powerful,
which naturally avoids duplicating .class files, and which is frankly
more natural all over. I can imagine this approach not working out for
some reason or reasons, since I've of course not totally thought it
through, but if it won't work, I'd definitely like to know precisely
*why*.

It's quite possible, of course, that you've already invested a lot of
time into making Any work, and found that it doesn't work because of
certain obscure, highly technical points that I have not yet stumbled
upon. But if that's the case, then neither the design document for
specialization, nor your above email, hints at what these issues might
be. At the very least they should be highlighted in the paper so that
the Java community understands what they are.

Happy new year!


--
Gavin King
gavin at ceylon-lang.org
http://profiles.google.com/gavin.king
http://ceylon-lang.org
http://hibernate.org
http://seamframework.org