I'm not sure how the API would look like either, but clearly the
"reflection approach" is not enough since it better represents runtime
types than compile time types. Just getting the relationships between the
things is hard to get today. We probably need something better for
synthetic union/intersection types, as it's very hackish today.

2018-04-08 20:57 GMT+02:00 Jochen Theodorou <blackd...@gmx.org>:

> On 08.04.2018 20:46, Cédric Champeau wrote:
> [...]
>
>> Honestly I don't have much time to work on Groovy. And if I had, the
>> generics STC bugs would be the last thing I'd like to get my hands into.
>> The ClassNode infrastructure was retrofitted to introduce generics back in
>> 1.5, but since it was for dynamic world, it wasn't really designed for what
>> we do now.
>>
>
> the structure was designed to closely represent what we get through
> reflection from Java, to make it easy to make this available. Of course in
> Java too generics are like an not so well fitting add-on. But since you
> keep coming with this I am curious in what you specifically miss, that must
> be in ClassNode
>
> So, every bugfix you make is likely to introduce another bug somewhere
>> else. That makes the process very painful. More so when type inference
>> enters the game. Jochen and I spent a lot of time writing, rewriting helper
>> methods to make this easier, but it's just too hard for the little time I
>> can afford.
>>
>
> fixing generics bugs usually takes long. But I really wonder how the API
> would have to look like to make this easy. I am not having enough fantasy
> for that it seems
>
> bye Jochen
>
>

Reply via email to