PROPOSAL: language support for JSR 292

[John Rose]

On Apr 3, 2009, at 1:25 AM, Joseph D. Darcy wrote:

> Reiterating a point Neal raised, if Dynamic is not related to Object,
> what does that mean when Dynamic is used as the format type argument  
> to
> a type parameter?  What do "? extends Dynamic" and "? super Dynamic"
> mean to the type system?

It means something limited like ? extends String or ? super Object.   
I.e., there aren't any interesting types other than Dynamic itself  
that match the wildcard.

> Actually there is a special rule that catching Exception is always  
> okay
> per JLS 11.2.3; this program is legal and compiles fine:
>
> public class Test {
>    public static void main(String... args){
>    try {
>        ;
>    } catch (Exception e) {
>        ;
>    }
>    }
> }
>

Thanks.  Amending the example to IOError.

>
> So what are the notions of identity and equality for method handles?

Inherited from Object. Nothing special.

> [snip]
>> 4.1 As specified above, the interface java.dyn.Dynamic has no
>> supertypes or members.  As such, it is a bare reference type.  (As an
>> arbitrary relation, the superclass of Dynamic[] is Object[].)  We
>>
>
> Are there any other type building operations besides arrays we need to
> worry about?

I don't think so.

List<Dynamic> is impossible for interesting reasons.  The (erased)  
implementation of List internally makes use of Object.toString,  
Object.equals, and perhaps other such methods.  These calls are wrong  
for Dynamic values, since Dynamic (not being a subtype) does not  
inherit Object.equals and the rest.  This allows a Dynamic object to  
cleanly model another language, without holes in its method namespace.

(Consider a process-oriented capability for which the name "wait" is  
significant, or some knowledge representation language that has  
different notions about "equals".  The MOP doesn't need to special- 
case those names.  It's a small point but worth defending, I think.)

(In C#, with reified types, they can customize their List<Dynamic> to  
make a MOP-mediated call to equals, I suppose.)

>> But, the Java operators "==" "!=" "+" "+=" on reference types are
>> clarified to apply only to reference types which are java.lang.Object
>> or one of its subtypes; they do not have a predefined meaning if
>> either operand is dynamic.  The "synchronized" and "throw" statements
>> cannot be applied to dynamic expressions.
>>
>
> So if there is no predefined meaning, are those operations illegal?

Yes.  More specifically, they are reserved for future use, in case we  
want to do something with dynamic operator overloading.

(There's a half-baked sketch of what this could mean someday, on the  
mlvm wiki.  It's not ready to discuss yet.)

>> Facilities which compute type relations (such as
>> javax.lang.model.util.Types) may need to be updated to take Dynamic
>> into account.  Generally speaking, the new Dynamic conversions  
>> operate
>> in parallel to the implicit boxing conversions.  That is, they add no
>> new subtype or supertype relations, but they provide a few more ways
>> for values to be implicitly converted or casted.
>>
>
> Yes, I would expect a few changes to the type-related APIs.  They may
> also need to be changes to programs that assume Object is the root of
> the reference type hierarchy.  I know I've written annotation  
> processing
> code like that and Dynamic would need to be special cased in there.

Thanks.

As noted in the previous message, I have updated the proposal.

-- John