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

[Gavin King]

Right, so this is the biggest objection to the idea of implementing
Any at the VM level: it would let you avoid boxing for the built-in
primitives, which is big win, obviously, but not for arbitrary value
types, which would still need boxing.

How strong of an objection this is depends upon how often you think
value objects will occur compared to primitives. That's a question
I've been turning over in my head the last couple of days, without
being able to really arrive at a firm conclusion by intuition alone.
Looking at Java as it exists today, it might be that Optional is the
one thing that really tips the balance. But on the other hand, it's
hard to say what people are going to do with Java once value types
exist; perhaps value types will eventually become the default choice
for most user-written classes!

The other thing floating around in the back of my mind is that even if
a VM-level Any isn't that useful for *Java*, it would still surely be
extremely useful for other JVM languages. I can imagine that folks
running dynamic langs on the JVM would just *love* to be able to use
an array of type Any[], and have that efficiently store numeric values
without boxing. The "specialization" approach doesn't seem like it
would help them as much. (This is speculation on my part; I've not
tried to compile dynamically-typed code for the JVM myself.)


On Mon, Jan 5, 2015 at 12:00 AM, Stephen Colebourne
<scolebourne at joda.org> wrote:
> The specialization document include the phrase "If we were concerned
> only about primitive instantiations, we could consider some sort of
> "tagged fixnum" approach. However, this approach essentially reverts
> to boxing for arbitrary value types, so it does not get us to our
> goal."

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

-- 
Gavin King
gavin.king at gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org