PROPOSAL: language support for JSR 292

[John Rose]

On Mar 29, 2009, at 7:55 AM, Josh Suereth wrote:

> I'm curious as to why you chose to not allow catching checked  
> exception from
> Dynamic method calls

That's a very good point.  In fact, invokedynamic (like any other  
invokex) can throw any kind of exception at the JVM level.  Since at  
the Java level it is untyped and therefore not statically checked, it  
must be possible, though not required, to catch checked exceptions.

Thanks!

On Mar 29, 2009, at 12:55 AM, Neal Gafter wrote:

> Could you please send the proposal to this list?

Done.

> I don't really understand the intended specification with respect to
> Dynamic.  It is one the one hand described as an object type (e.g.
> section 1.9)

Dynamic is a reference type, but not a subtype of Object.  This means  
it does not have the methods of Object.  I don't think I used a phrase  
meaning "object type".

> but on the other hand it doesn't inherit from Object
> (section 1.1).  You can't have it both ways.  I can't tell, for
> example, whether Dynamic is a valid type in a generic type parameter.

I haven't decided yet if the language of the JLS for GTP's should have  
special pleading to allow Dynamic to have a type upper bound (and to  
erase) to Object, analogous to the special pleading I wrote that  
Dynamic[] is a subtype of Object[].  The JLS rules as they stand today  
make it impossible to have List<Dynamic>.

> If the answer is yes, then it must have Object as a supertype.

Unless the type bound is itself Dynamic; then the JSL rules as written  
currently would allow Dynamic itself as a GTP.  What they won't allow  
(as written) is Dynamic to be the GTP for a type variable bound by  
Object (or something else other than Dynamic).

Hmm...  If it's useful to have a field or return value or array  
element of type Dynamic, it is equally useful to have List<Dynamic>.   
So I guess, yes, there needs to be a special pleading, a tweak about  
Dynamic and type bounds.  The kind of tweak which won't cause a  
cascade of further tweaks--I don't know yet if that is possible.  Can  
you give me a reference to what C# does about dynamic vs. type bounds?

I suppose we could declare that Dynamic *does* have Object as a super  
class, but somehow hides all the inherited methods, even the ones that  
are final.  That would be a different tack.  That would require some  
special pleading in rules for method resolution; maybe that would be  
simpler.

Regardless of the specification details, the overall goal is to make  
Dynamic into a type which has even less static content than Object,  
but allows any method call to be switched through invokedynamic.

> You
> might find it useful to review what C# has done in this area with
> their type "dynamic".

Yes, while working on this proposal I just saw Jim Hugunin present at  
PyCon; he gave a brief introduction to dynamic in C# 4.0.  For my  
part, it was another funny case of parallel evolution between C# and  
Java.  Not so funny for us, actually, that C# is releasing while Java  
is just cogitating.  Snail-like pace is the price of multi-vendor  
standarization.  Or of the compatibility requirements of success.  Or  
of downsizing.  Or something.

> In short, it occupies the same location in C#'s
> type lattice as Object, but it has some additional conversions defined
> that are not subtype relationships.

That's exactly what I am trying to do, if what you mean by "same  
location" is "peers at the same depth".  If they were truly at the  
same location in the type lattice, wouldn't they be the same type?   
Perhaps I'm missing something here.

Thanks for the prompt and incisive comments, Neal.

-- John