Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: supercalifragilisticexpialadiamaticonormalizeringelimatisticantations Newsgroups: comp.lang.java.programmer Subject: Re: looping through a list, starting at 1 Date: Fri, 12 Aug 2011 09:09:40 -0400 Organization: supercalifragilisticexpialadiamaticonormalizeringelimatisticantations Lines: 75 Message-ID: References: <4e3745a2$0$305$14726298@news.sunsite.dk> <62239393-929c-4764-8c8e-9620a03a7b81@c29g2000yqd.googlegroups.com> <80346568-647c-4e27-8192-33e1765a09ce@glegroupsg2000goo.googlegroups.com> <4b71d212-c055-4af0-b9a9-13e3afbc5785@glegroupsg2000goo.googlegroups.com> <5b7d8805-7c33-4aa4-9b31-ae60c29a31f3@glegroupsg2000goo.googlegroups.com> NNTP-Posting-Host: E/slOOVLkaS2xbKmPsXNLA.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: WinVN 0.99.12z (x86 32bit) X-Notice: Filtered by postfilter v. 0.8.2 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:7037 On 12/08/2011 4:32 AM, Andreas Leitgeb wrote: > Lew 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.