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


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

Re: looping through a list, starting at 1

From supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com>
Newsgroups comp.lang.java.programmer
Subject Re: looping through a list, starting at 1
Date 2011-08-12 09:09 -0400
Organization supercalifragilisticexpialadiamaticonormalizeringelimatisticantations
Message-ID <j238mf$kv9$1@speranza.aioe.org> (permalink)
References (7 earlier) <slrnj47vhe.6gl.avl@gamma.logic.tuwien.ac.at> <4b71d212-c055-4af0-b9a9-13e3afbc5785@glegroupsg2000goo.googlegroups.com> <slrnj486bs.6gl.avl@gamma.logic.tuwien.ac.at> <5b7d8805-7c33-4aa4-9b31-ae60c29a31f3@glegroupsg2000goo.googlegroups.com> <slrnj49p84.6gl.avl@gamma.logic.tuwien.ac.at>

Show all headers | View raw


On 12/08/2011 4:32 AM, Andreas Leitgeb wrote:
> Lew <lewbloch@gmail.com>  wrote:
>> And my point was that there often is a way to put that
>> bifurcation into a compile-time structure rather than
>> run time.
>
> For classes I design myself: yes. It's called "virtual
> methods" and is a standard feature of Java ;-)
>
> That just isn't an option for foreign library classes
> if the "bifurcation" happens in my own code.

...

> I'm still eager to see an alternative to "instanceof"
> for the RandomAccess-case.

I wonder what the odds are of Java 8 adding a variant of switch/case 
like this?

switch class (object) {
     case java.util.RandomAccess:
         // code goes here
         break;
     case java.util.List:
         // code goes here
         break;
     // ...
     case null:
         // code for if object is null goes here
         break;
     default:
         // code goes here
}

For when you don't control the classes yourself, but need to dispatch on 
their type in new code. It could compile into something as efficient as 
an invokevirtual, or nearly so, e.g. a jump through a hashed lookup 
table keyed by the object's hidden class field. The commonest use case 
would undoubtedly be in implementing equals methods in hierarchies that 
have mutually comparable subclasses, and the second commonest would be 
strategy dispatch like you wanted with RandomAccess the deciding factor, 
and maybe also clearly breaking out "if null" special cases.

The other way to implement something like this would be a run-time 
overload resolution option, say something like:

public volatile int method (RandomAccess list) { ... }
public volatile int method (List list) { ... }
public volatile int method (null) { ... }

Hypothetically, the compiler basically turns this into a single method 
accepting type List with the above switch inside, minus default clause, 
and with the type of "list" being cast as appropriate inside the code 
blocks.

Alternatively, just call it double dispatch. :) The null case has no 
local variable "list" available. Either every overload of "method" is 
"volatile", none are, or it's an error. The added dispatch is on the 
type of the first argument, and it must be a reference type. The most 
specific matching type is chosen, and if there are two equally specific 
alternatives this is a run-time error, but a parameter type of 
(Interface1 && Interface2) or similar is permitted to add an 
intersection case to alleviate such errors. A new RuntimeException 
subclass AmbiguousDispatchException can be added for that case. 
Alternatively, it could be a compile-time error for there to be two 
interface dynamic overloads but no intersection overload. Alternatively, 
the "default" keyword could be added somewhere to make one of two 
interface overloads preferred over the other when both matched. I'd 
expect that to be rare, though, as the common-case choices would be over 
concrete classes or a family of related successively narrower interfaces.

As near as I can tell, none of the above proposed syntax extensions 
breaks backwards source compatibility or requires class format/JVM 
changes to implement; just javac enhancements.

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