Hi Jesper.
Thanks a lot for digging this out. Indeed this sounds like a "nice"
little project in its own... I wonder whether instead it would make
sense to instead implement something simpler that would be incomplete
but still work for common cases. For instance, our example makes no
use of generics, so one could, for instance, first implement a version
that ignores the issue of generics.
(on the other hand it may also be just as easy or hard to implement it
right - it's hard for me to tell)
Eric
On 21 January 2013 16:34, Jesper Öqvist <jesper.oqvist_at_cs.lth.se> wrote:
> My original answer to why it is so complicated was incorrect. It was a while
> since I looked at this last time, so I forgot some of the details, I've been
> reading the specification now
> (http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.12.2.7)
> and here is my revised answer to why the LUBType computation is complicated:
>
> The lub type is used in method type inference when there are some type
> bounds U_1 ... U_k inferred from the context. We need to find a type T_j
> that fits these bounds. First we construct the sets of all supertypes of all
> type bounds ST(U_i) and in order to intersect these sets we need to take the
> erased versions of the types in the supertype sets. Now we can get a type
> that fits the bounds, but it is erased. Finding the type arguments (if the
> result type was generic) is the hairy part where things become very fiddly.
>
> TL;DR; generics complicate things.
>
> /Jesper
>
>
>
> On 01/18/2013 04:20 PM, Eric Bodden wrote:
>>>
>>> The type of an expression such as the one in your example is incorrectly
>>> evaluated in JastAddJ currently.
>>> This has been known for some time know. I added the bug on the issue
>>> tracker
>>> when I was working on Java 7.
>>>
>>> It's not something that we can easily fix, if you have any suggestions I
>>> would be all ears! The type analysis concerning LUBType is *very*
>>> complicated. I was planning to work through it at some point and try to
>>> get
>>> an understanding of why it currently doesn't work but right now I have no
>>> clue.
>>
>> Thanks for conforming. I wonder: why is this so hard? At least for
>> reference types, don't you "just" have to search for the common first
>> ancestor in the class hierarchy?
>>
>> Cheers,
>> Eric
>
>
> _______________________________________________
> JastAdd mailing list
> JastAdd_at_cs.lth.se
> https://mail1.cs.lth.se/cgi-bin/mailman/listinfo/jastadd
--
Eric Bodden, Ph.D., http://sse.ec-spride.de/ http://bodden.de/
Head of Secure Software Engineering Group at EC SPRIDE
Tel: +49 6151 16-75422 Fax: +49 6151 16-72051
Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt
Received on Mon Jan 21 2013 - 17:14:17 CET