Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!feeder.erje.net!newsfeed.utanet.at!newscore.univie.ac.at!aconews-feed.univie.ac.at!aconews.univie.ac.at!not-for-mail
Newsgroups: comp.lang.java.programmer
From: Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at>
Subject: Re: looping through a list, starting at 1
References: <list-20110802003845@ram.dialup.fu-berlin.de> <4e3745a2$0$305$14726298@news.sunsite.dk> <62239393-929c-4764-8c8e-9620a03a7b81@c29g2000yqd.googlegroups.com> <j19jcs$fad$1@Gaia.teknon.de> <80346568-647c-4e27-8192-33e1765a09ce@glegroupsg2000goo.googlegroups.com> <slrnj45uke.6gl.avl@gamma.logic.tuwien.ac.at> <edffc0ad-6325-4622-93b4-abff84190e79@glegroupsg2000goo.googlegroups.com>
Reply-To: avl@logic.at
User-Agent: slrn/pre0.9.9-111 (Linux)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <slrnj47vhe.6gl.avl@gamma.logic.tuwien.ac.at>
Date: 11 Aug 2011 16:07:10 GMT
Lines: 72
NNTP-Posting-Host: gamma.logic.tuwien.ac.at
X-Trace: 1313078830 tunews.univie.ac.at 71616 128.130.175.3
X-Complaints-To: abuse@tuwien.ac.at
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:7021

Lew <lewbloch@gmail.com> wrote:
> Andreas Leitgeb wrote:
>> Lew wrote:
>>> Volker Borchert wrote:
>>>> if (l instanceof RandomAccess) {
>>> Tests on type like this are an antipattern.
>> Are marker-interfaces (which RandomAccess is, iirc) already an
>> antipattern, or is there a different way to check for them, [...]
> With generics you can use type intersections so that something has to be
> both 'List' and 'RandomAccess' (again, say) even to reach the call or the
> class or whatever.

Interesting stuff! (but still falls a bit short):

--- snip SSCCE Test.java ---
import java.util.*;
public class Test {
    public static void main(String[] args) {
        method( new ArrayList(42) );
        method( new Vector(42) );
        //method( new LinkedList(42) ); // would error: good!
    }

    public static <T extends List,RandomAccess> T method(T raAcList) {
       return raAcList;
    }

    //Provide a fallback overload for all Lists: doesn't compile
    // public static <T extends List> T method(T anyList) {
    //    return anyList;
    // }

    //Nor does this compile together with the generic one:
    // public static List method(List anyList) {
    //    return anyList;
    // }
    //with Object for the param-type it would compile, but not
    //help to filter for Lists at compile-time.
}
--- snip ---

So, while I could write a method that takes only objects which are
both List and RandomAccess, I cannot provide a less-picky overload,
that would only filter on List.
(This appears like a shortcoming to me, which may eventually be
fixed, but it doesn't work with 1.6.0_26.)

> It's the run-time type check that one often wishes to avoid.
> Of course, if the logic truly requires it, as it sometimes does,
> then the antipatternness goes away.  I just find that use of
> 'instanceof' in the world of types and generics frequently
> signals incompletely thought-out type assertions.

Well, for now, I guess we'll just have to face that it is necessary
more often than it would be in an ideal Java.

> If there were an SSCCE for the particular use case, one might
> be able to discern a less run-timeish way forward or one might not.

The case at hand didn't really suffer from the distinction. 
The object is asked at runtime if it is a RandomAccess, and
either way correct (hope so) and appropriate code is executed
for the object.  It's not principially different from asking
a (list-)object if it is empty(), and do something appropriate
in each case.

> I only wished to point out a general principle here.

Thanks for pointing out the trick with generics, even though
it doesn't yet fully work. I hadn't thought of that, and might
run into a situation where it could prove useful.