<div dir="ltr"><div class="gmail_extra">







<p class="">(Sorry if this message doesn’t appear in the same thread; I didn't get the older messages on the list).</p>
<p class="">I’d like to suggest a slightly different approach to the containers migration issue (I'm not discussing equality). </p>
<p class="">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:</p><p class="">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 superation.</p><div>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.</div><div><br></div><div>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- <i>and</i> subtypes of T (as in, animals.contains(dog)). I believe its type — like that of equals() -- should be <any T> contains(T x)<br></div>
<p class=""><br></p><p class="">Ron<br></p></div></div>