Jochen Theodorou wrote:

You can think of the current method resolution like this:

(1) send the types to the metaclass and have it figure out what method to invoke.

With the first proposal, this becomes:

(2) if (types & metaclass are as expected) { call associated method } else { send the types to the metaclass and have it figure out what method to invoke. }

The question is: if the programmer says they expect certain types & metaclass, but at runtime we find something different, is that an error? Sometimes it will be, sometimes it won't be. It depends on whether the programmer was thinking "these types will usually be what I said, but sometimes won't" vs. "from the way I designed the code, these expressions should always have these types. If they don't, something's wrong." For the latter, we get:

(3) if (types & metaclass are as expected) { call associated method } else { throw execption }

That makes the type declaration the same as an assertion. You could imagine having an optimized build which doesn't even check:

(4) call associated method

Of course, you'd only want to turn off the type checks after you've thoroughly debugged, profiled, and found them to be a bottleneck. (I don't understand why Java even has a switch to turn off all assertions globally; turning off the ones that aren't a bottleneck can only lead to confusing messages or even corrupt data. And it really boggles my mind that they're off by default. Oh well.)

Option (2) is essentially what call site caching does, where "expected" is what was seen last time. But it doesn't allow (3) or (4). Whether that's a problem or an advantage depends on your point of view. ;)

Best, Martin

--------------------------------------------------------------------- To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email