Migrating methods in Collections
ron at paralleluniverse.co
Sun Dec 20 17:40:40 UTC 2015
(Sorry if this message doesn’t appear in the same thread; I didn't get the
older messages on the list).
I’d like to suggest a slightly different approach to the containers
migration issue (I'm not discussing equality).
The partial-method idea seems a potential source of confusion to me. Unlike
techniques for manual specialization (e.g. bitfields for
ArrayList<boolean>), here we’re talking added complexity which directly
affects any interaction with a generic class — not just its implementation.
It is unencapsulated complexity, so I think it deserves careful
consideration. I have a couple of ideas, each can be used in isolation or
in a combination with the other, which may (or may not) be simpler:
1. We can simply not specialize the signatures of public collection methods
(say, if [T] is the boxed-type of T, the signature of Map<K,V>.get(Object)
will be [V] get(Object)). The JVM’s ability to avoid boxing might be good
enough for this to yield the performance we want. New methods can, of
course, be added. This approach can be taken in addition to or instead of
2. If methods are to be removed (as in made partial), instead of magically
disappearing them at the call site based on usage, perhaps we should
consider hiding them by source-code version (not from the class file, of
course, only hiding them in javac)? This is an explicit decision to break
source compatibility, but it has two mitigating factors: 1/ javac
conveniently has a source level (which, I hear, will also result in hiding
new methods starting with Java 9) and 2/ Java already breaks source
compatibility from time to time. I had quite a few classes that didn’t
compile under 8 because 8 changed the name resolution rules wrt static
imports (or, more precisely, made them conform to the JLS, whereas they
hadn't in prior versions). It took me some time to figure out what was
wrong, but hidden methods would be able to give much better error messages.
Also, the superation idea seems very interesting, but I don’t understand
how it would work for contains/remove(Object), as contains needs to be able
to accept both super- *and* subtypes of T (as in, animals.contains(dog)). I
believe its type — like that of equals() -- should be <any T> contains(T x)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the valhalla-spec-experts