Lambda the Ultimate

inactiveTopic Covariant methods in Java
started 1/25/2001; 8:00:38 AM - last post 1/26/2001; 7:56:36 PM
andrew cooke - Covariant methods in Java  blueArrow
1/25/2001; 8:00:38 AM (reads: 1392, responses: 4)
Covariant methods in Java
If you really want to, here's how to hand-code it using reflection...

Seen at HtP.
Posted to "" by andrew cooke on 1/25/01; 8:01:12 AM

Chris Rathman - Re: Covariant methods in Java  blueArrow
1/25/2001; 2:32:45 PM (reads: 1436, responses: 0)
Sounds interesting. In the conclusion was the statement about:

Creating a generic dispatcher. It is possible to create a class which implements the dispatcher in a generic manner in order to avoid duplicating the code in every class where you want to use covariance. Such a generic dispatcher could implement finding the name of the method to be executed, method selection, method invocation, primitive parameter type handling, and invariant overriding.

If such a dispatcher could be written, then one could simply make a call to the generic method, sending the 'this' object, the function name & parameters and have it do all the dispatching.

On the downside, the dispatch routine would pretty well have to mimic the rules as established in the Java compiler. Selecting the best fit for a function can get involved (and expensive in terms of time). Hmmmm.... Guess I'm gonna have to play around with it a bit to see how involved the solution actually is. :-)

Chris Rathman - Re: Covariant methods in Java  blueArrow
1/26/2001; 9:59:15 AM (reads: 1430, responses: 0)
Well, I haven't gotten very far but I did do a first stab at Shape Covariance in Java. No particular reason to use shapes, other than not having to think about the domain at all. The dispatch routine handles the case of one parameter that has the exact signature of the specialized class.

Will refine later when I get the time. :-)

Chris Rathman - Re: Covariant methods in Java  blueArrow
1/26/2001; 2:25:12 PM (reads: 1411, responses: 0)
I tweaked the dispatcher a bit more using the suggestions from the original article. I still don't support multiple parameters or primitives. The primitives shouldn't be too much trouble, but it's a level of complexity I don't want to deal with at the moment.

The hard part is adding multiple parameters because you may not get one best answer. Gonna have to go study up on the language spec to figure out the algorithm.

One thing I did notice is that the original article seems to ignore function return values. I added support into the dispatch to handle having the methods return values, but the question of primitives also arises on the return result. Think I'll leave the dispatch routine alone and let the caller to the method unpack a primitive from the Objects (Integer, Float, etc...).

Chris Rathman - Re: Covariant methods in Java  blueArrow
1/26/2001; 7:56:36 PM (reads: 1414, responses: 0)
Would you believe that the third time is a charm. I've added support for multiple parameters, primitives and just generally cleaned things up. Probably be where I leave it for awhile.

Just a quick note about some quirks. First, the way the primitives are handled is that they are boxed into their object cousins. This works fine except you may run into situations where you have two methods that have the same perceived signature even though one is declared with a primitive and the other with an Object the corresponds to that primitive. The dispatcher masks any possible difference between the two. These two methods would be considered identical by the dispatch (Both will look like they take an integer object):

void aMethod(int aPrimitive) true

void aMethod(Integer anObject) true

Personally, I think of this as a feature since I don't necessarily like the differentiation between primitives and objects. Additionally, I don't think it would be a good programming practice to have these methods actually do something distinct - they should be identical except for the fact that one uses the primitive operations and the other uses the object operations. Should mean that all things being ideal, which method is chosen in this scenario is irrelevant.

Beyond that, I didn't test whether more than one maximally specific method is supported. I just go through and find one that is most specific (on a left to right basis). This is not necessarily the technique used by the Java compiler. It also doesn't flag a runtime error when the Java compiler would normally indicate that selecting the method is indecisive.

My thinking here is that the overhead added to check for variations is more than it's worth at this time. Covariance using this technique has a lot of loss ends anyhow, so this is just one more thing to take into consideration.

Among other things, I also didn't worry about the (a) handling of exceptions; (b) possible accessibility mismatches; and (c) invariant overriding.