PROPOSAL: language support for JSR 292

John Rose John.Rose at Sun.COM
Tue Mar 31 16:01:43 PDT 2009


On Mar 29, 2009, at 5:34 PM, Rémi Forax wrote:

> John, your proposal doesn't cleanly separate the four parts of the  
> proposal
> thus this is really hard to read (at 2 am :)

Hi, Rémi!

Everything is numbered #1 to #4, and I tried to keep the strands  
separate.  Are there places where points about #n leak into section  
#m, m!=n?  (Does it look better by daylight? :-)

> Correct me if i'm wrong,
> the purpose of Dynamic as a type is to
> 1) be able to do an invokedynamic wich is receiverless using a dot.
>    Dynamic x=...
>    x.m() // is translated to invokedynamic m(Dynamic)

Three purposes, which are loosely coupled, hence proposed together:   
#1 marker for static-syntax sites Dynamic.foo(...).  #2 bare reference  
type with sugar d.foo(...) == Dynamic.foo(d, ...).  #4 bare reference  
type with extra conversions, to make #2 easier to work with.  (#3 is  
for exotic ids.)

> 2) to have more conversions from/to Dynamic than from/to Object.

That's #4.

> Else, I would prefer null not being infered as Void instead
> the compiler should raise an error and let the user cast it
> to Object, Dynamic etc.

I went back and forth on this point while I was working with the  
code.  At first (a) null was implicitly Object, then (b) it caused an  
error (as you suggest), then (c) it uses a marker type Void.  The most  
correct thing would be (d) to use Neal's marker type Null, but this  
doesn't exist yet.  I settled on (c) as an approximation to (d),  
because I considered the use case of simulating Java call sites, and  
null is fundamentally different from any other type; therefore it need  
to be reified somehow.  There is no real downside to using the hack  
type Void even if (d) becomes available, since the only consumers of  
those type references are bootstrap methods (MOP machinery), and they  
will always need some sort of special case for null types anyway; the  
special casing can be extended to Null and Void deprecated when the  
time comes.  Also, this use of the type Void has no impact on  
statically typed Java code.

Does that help explain?

I'll add this to a FAQ on the wiki page.

-- John



More information about the coin-dev mailing list