When feeding an invocation expression such as Long.valueOf(1) to dryad-front, no WideningPrimitiveConversion annotation is produced. The annotation is essential in this case (literal 1 is typed as an integer, and Long.valueOf expects a long), and is already produced for assignment conversions.

Submitted on 6 February 2007 at 14:01

DRY-246, martin:

Ah, from our earlier discussion I got the impression that this method call was not typed at all, which surprised me. But, the only problem seems to be that there is no conversion annotation.

I now remember why I still haven’t done this: I was unsure where to attach the annotation to. I used to think that it cannot be attached to the argument, since that argument might itself have conversion annotations. However, there will never be method invocation conversion annotations there, so it might be ok to just have multiple kinds of conversions attached to these arguments.

What’s your opinion on this?

DRY-246, martin:

uh, I forgot that I already solved this :o There is actually support for a Conversions attribute (so I solved this annotation problem in a different way then just described).

The problem is not really the conversion: the method is applicable by subtyping, which strictly speaking does not use a method invocation conversion. An int is a subtype of long, that’s why the method is applicable.

Of course, this does not help you much, since you still want information about why the method was applicable and what kind of conversions you have to do. I think it would be good to attach information to the invocation that the method was applicable by subtyping. Based on this subtyping, it should then be possible to figure out separately what kind of conversions to perform.

DRY-246, lennartkats:

I haven’t read the specification on this, but it just strikes me as odd that there are no widening primitive conversions annotated in the above case, but there are if there is also a boxing conversion, as in the following example:

$ echo ‘class Foo { void bar(long l, long l) { bar(new Integer(1), 2); } }’ | dryad-front –tc on | pp-aterm
[…]
Conversions(
[ MethodInvocationConversion(
[ UnboxingConversion([…], Int)
, WideningPrimitiveConversion(Int, Long)
]
)
, MethodInvocationConversion([WideningPrimitiveConversion(Int, Long)])
]
)
[…]

Anyway, I’m happy as long as you make the information available for use in one way or another. Most straightforward would perhaps be to use a wrapper tag other than MethodInvocationConversion? And as we discussed it could also be nice to put annotations locally on each parameter instead of using a list of annotations for the whole invocation…

DRY-246, lennartkats:

So how about adding a “Subtyping” attribute with all WideningPrimitiveConversions, IdentityConversions and UncheckedConversions involved? That should be a quickie fix, and pretty close to the spec which uses these terms for the MethodInvocationConversion.

DRY-246, martin:

Hm, right, I forgot about this issue …

Indeed, I think that we should attach the method invocation with all the information about how this method was applicable. This includes information on the method being applicable by subtyping.

About the conversions: I’m not sure yet, but maybe we need a separate strategy that determines the conversions necessary …. Strictly speaking, the specification of method invocations does not say anything about these conversions, that’s why I suspect that doing this in a separate strategy would be good. The same strategy might also be necessary in different situations.