Lambda the Ultimate

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. :-)

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

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...).

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.