Re: Parent class of a trait

Hi again,

I've tried to track down exactly where this information about the
actual base class "gets lost". It seems to happen during the 'erasure'
phase. Can you confirm this?

And if so, is there a way to skip this phase? I've tried, and
apparently the 'constructors' phase depends on it (i.e. it throws an
exception if I just comment out the 'erasure' phase). Do other phases,
such as lazyVals, lambdaLift, flatten, mixer or cleanup, depend on the
'erasure' phase as well?

Cheers

Valentin

On Mon, Aug 24, 2009 at 9:58 PM, Valentin Wüstholz<wuestholz <at> gmail.com> wrote:
> Thanks! My example input is this:
>
>> trait T
>> class C
>> trait U extends C
>
> Now when I process the AST (just before code generation) for trait U,
> I would like to know what the base class of U is (C in this case). But
> the 'parents' field in the AST contains the base class of the base
> class (Object in this case), as you explained earlier. I don't
> understand why you don't store the base class and all mixed in traits
> in the parents field instead. Or is there another way to extract the
> fact that U extends C from the AST? That would be fine for me.
>
> Was that more understandable?
>
> Cheers
>
> Valentin
>
> On Mon, Aug 24, 2009 at 6:19 PM, martin odersky<martin.odersky <at> epfl.ch> wrote:
>> On Mon, Aug 24, 2009 at 2:47 PM, Valentin Wüstholz<wuestholz <at> gmail.com> wrote:
>>> Thanks for the clarification! That was also what I suspected.
>>>
>>> But I don't quite understand why you store the superclass of the
>>> actual base class. Don't you lose some information that way? Or is
>>> this just something you don't need in your code generator?
>>
>> I am not sure I understand. What's your input and AST exactly?
>>
>>  -- martin
>>
>