Points about language support for 292
    Alex Buckley 
    Alex.Buckley at Sun.COM
       
    Thu Apr 30 15:15:08 PDT 2009
    
    
  
Hi John,
1.1: "The complete lack of supertypes makes it an unusual type, on a par 
with Object."
But InvokeDynamic is defined as a class with a superclass of Object a 
few lines earlier. The text in () looks redundant.
1.5: As the JVM executes, checked exceptions may be produced by any 
invokedynamic call.
Please don't put "JVM" and "checked exceptions" in the same sentence! 
More importantly, I don't agree with "the possibility of a missed catch 
of a checked exception is not considered to be a hazard." An exception 
handler further up the stack that catches unchecked exceptions will miss 
it, and the program will in all likelihood stop.
In other words, this is a relaxation too far of static exception 
checking. One option is to have InvokeDynamic.foo() claim to throw all 
possible checked exceptions. If one actually leaks back to the call site 
from a dynamic language's runtime, it should be caught right there.
Another option, and perhaps a better one since it partitions 
InvokeDynamic off from checked exceptions entirely, is to specify that 
its infinite static methods can throw only unchecked exceptions (or one 
in particular, if you like). An implementation would have to wrap 
checked exceptions.
Neal: InvokeDynamic IS now a reference type. Regarding <..> to indicate 
return type for a dynamic call site, how does C# denote that?
Alex
    
    
More information about the coin-dev
mailing list