Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #7010

Re: looping through a list, starting at 1

From Arved Sandstrom <asandstrom3minus1@eastlink.ca>
Newsgroups comp.lang.java.programmer
Subject Re: looping through a list, starting at 1
References (3 earlier) <j19jcs$fad$1@Gaia.teknon.de> <80346568-647c-4e27-8192-33e1765a09ce@glegroupsg2000goo.googlegroups.com> <slrnj45uke.6gl.avl@gamma.logic.tuwien.ac.at> <DlD0q.35597$g12.31437@newsfe20.iad> <slrnj462qe.6gl.avl@gamma.logic.tuwien.ac.at>
Message-ID <fNN0q.575745$SG4.165292@newsfe03.iad> (permalink)
Organization Public Usenet Newsgroup Access
Date 2011-08-11 07:02 -0300

Show all headers | View raw


On 11-08-10 07:50 PM, Andreas Leitgeb wrote:
> Arved Sandstrom <asandstrom3minus1@eastlink.ca> wrote:
>> On 11-08-10 06:39 PM, Andreas Leitgeb wrote:
>>> Lew <lewbloch@gmail.com> wrote:
>>>> Volker Borchert wrote:
>>>>> if (l instanceof RandomAccess) {
>>>> Tests on type like this are an antipattern.
>>>> Like many antipatterns there are occasions when one might
>>>> consider its use anyway, but it's a red flag that we're
>>>> probably going about things the wrong way.
>>>
>>> Are marker-interfaces (which RandomAccess is, iirc) already an
>>> antipattern, or is there a different way to check for them,
>>> or are marker-interfaces just one of the occasions where one
>>> would just acknowledge and consciously ignore the red flag?
>>>
>>> PS: I fully agree with your judgement *outside* the context
>>>   of marker-interfaces, and am eager to learn *inside* that
>>>   context.
>>
>> I don't see that marker interfaces are an anti-pattern. I believe that
>> Bloch's comments with respect to marker interfaces (Item 37 in Effective
>> Java) make sense: as he points out one ought to consider a marker
>> interface to be a type definition.
> 
> That doesn't make sense to me...
> I can trivially create a class that inherits Object and implements
> RandomAccess and doesn't offer anything of the Collection-stuff.
> 
> How would I write a method (overload) that would only take an
> object if it is both List and RandomAccess? (Afaik: no way, but
> I might perhaps miss something.)

Pretty much in the standard way, which would take advantage of the
marker interface in a way suggested by Bloch: you create an interface
that extends List and RandomAccess, and concrete classes implement that.

Your method simply has the appropriate argument type, and is
compile-time checked.

> Lew's argument absolutely makes sense for other types:
> Rather than checking for List l, whether (l instanceof ArrayList)
> I'd rather make one overload for ArrayList and another one for List.
> But I cannot do something like that to separate List&RandomAccess
> from List.

You can - see above. But if you wished to avoid 'instanceof' type
runtime checks, and work with overloads, your API for clients would have
to include that combination interface that client code which supplies
suitable objects agrees to implement.

Short of true multiple dispatch in Java I don't think this is a terrible
solution.

> It's not the "no-method"-ness of marker interfaces that matters here.
> They are just a trick to implement what could otherwise be implemented
> with a getter:  bool supportsRandomAccess(). As they don't do it with
> a method but with an interface, the syntactic way to obtain that "flag"
> is using instanceof.  I don't see why this would be red-flagged without
> red-flagging that concept of marker-interfaces altogether.
> 
You are talking about runtime type checking and taking implementation
actions based on that knowledge. Your latter paragraph applies to that
situation. I haven't been treating that situation.

I specifically answered your question "Are marker-interfaces (which
RandomAccess is, iirc) already an antipattern". IMO they are not, for
reasons stated. But this non-anti-pattern explanation emphasizes their
use as compile-time new types. Their not inconsiderable utility here
stems from the fact that the marker interface guarantees a behaviour in
a documented contract - it's up to the implementor to meet those guarantees.

AHS

Back to comp.lang.java.programmer | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Re: looping through a list, starting at 1 Arne Vajhøj <arne@vajhoej.dk> - 2011-08-01 20:32 -0400
  Re: looping through a list, starting at 1 Robert Klemme <shortcutter@googlemail.com> - 2011-08-02 02:42 -0700
    Re: looping through a list, starting at 1 v_borchert@despammed.com (Volker Borchert) - 2011-08-02 19:32 +0000
      Re: looping through a list, starting at 1 Lew <lewbloch@gmail.com> - 2011-08-10 09:00 -0700
        Re: looping through a list, starting at 1 Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-08-10 21:39 +0000
          Re: looping through a list, starting at 1 Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-08-10 19:10 -0300
            Re: looping through a list, starting at 1 Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-08-10 22:50 +0000
              Re: looping through a list, starting at 1 Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-08-11 07:02 -0300
                Re: looping through a list, starting at 1 Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-08-11 11:37 +0000
                Re: looping through a list, starting at 1 Lew <lewbloch@gmail.com> - 2011-08-11 07:14 -0700
                Re: looping through a list, starting at 1 Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-08-11 16:18 +0000
                Re: looping through a list, starting at 1 Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-08-11 17:39 -0300
                Re: looping through a list, starting at 1 Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-08-12 08:09 +0000
                Re: looping through a list, starting at 1 supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-08-11 09:52 -0400
                Re: looping through a list, starting at 1 Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-08-11 17:26 -0300
                Re: looping through a list, starting at 1 supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-08-11 20:11 -0400
          Re: looping through a list, starting at 1 Lew <lewbloch@gmail.com> - 2011-08-10 20:31 -0700
            Re: looping through a list, starting at 1 Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-08-11 16:07 +0000
              Re: looping through a list, starting at 1 Lew <lewbloch@gmail.com> - 2011-08-11 09:20 -0700
                Re: looping through a list, starting at 1 Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-08-11 18:03 +0000
                Re: looping through a list, starting at 1 Lew <lewbloch@gmail.com> - 2011-08-11 12:55 -0700
                Re: looping through a list, starting at 1 Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-08-12 08:32 +0000
                Re: looping through a list, starting at 1 supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-08-12 09:09 -0400
                Re: looping through a list, starting at 1 Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-08-12 14:38 +0000
                Re: looping through a list, starting at 1 Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-08-12 14:51 +0000

csiph-web