the erasure of Object with A

I'm in favour of it, this one has already bitten me and involved a certain amount of (minor) swearing...

On Fri, Dec 4, 2009 at 9:01 PM, Paul Phillips <paulp@improving.org> wrote:

Proposal: The erasure of "Object with A" is "A" instead of "Object".

Motivations:

1) Remove a bunch of checkcasts from bytecode.
2) Generated bytecode easier to use from java.  Example:

 def zipWithIndex = new Iterator[(A, Int)] { methods  }

At present this generates at the bytecode level a method with return
type Object.  If you call it from java you will have to cast it to
Iterator.  Right now to get the right return type in the bytecode, every
method which creates one must declare it explicitly.

3) More robust binary compatibility: right now if you change something
from a trait to an abstract class, in situations like the above the
return type will flip from Object to the class.  There's no reason
traits and abstract classes need to behave differently here.  This would
break binary compat right now (and now is surely the time to do it) but
from this point forward people could switch between trait and abstract
class without being hit by an unnecessary difference.

4) ... ?

Are there downsides? I haven't come up with any interesting ones, but it
wouldn't surprise me if someone else could.  I implemented this locally
and the whole test suite passed without modification.


Specification change.  Right now it says:

 The erasure of a compound type T1 with ... with Tn {R } is |T1|.

This would be altered to something like:

 The erasure of a compound type T1 with ... with Tn {R } is the first
Tn whose erasure is something other than Object.  (Is there a term for a
"top type" in the hierarchy after erasure? That's the term I'd be going
for here if I knew it.)

Some more background on this at:

 https://lampsvn.epfl.ch/trac/scala/ticket/1377

--
Paul Phillips      | Before a man speaks it is always safe to assume
Apatheist          | that he is a fool.  After he speaks, it is seldom
Empiricist         | necessary to assume it.
pull his pi pal!   |     -- H. L. Mencken

On Fri, Dec 4, 2009 at 10:01 PM, Paul Phillips wrote:
> Proposal: The erasure of "Object with A" is "A" instead of "Object".
>
> Motivations:
>
> 1) Remove a bunch of checkcasts from bytecode.
> 2) Generated bytecode easier to use from java.  Example:
>
>  def zipWithIndex = new Iterator[(A, Int)] { methods  }
>
> At present this generates at the bytecode level a method with return
> type Object.  If you call it from java you will have to cast it to
> Iterator.  Right now to get the right return type in the bytecode, every
> method which creates one must declare it explicitly.
>
> 3) More robust binary compatibility: right now if you change something
> from a trait to an abstract class, in situations like the above the
> return type will flip from Object to the class.  There's no reason
> traits and abstract classes need to behave differently here.  This would
> break binary compat right now (and now is surely the time to do it) but
> from this point forward people could switch between trait and abstract
> class without being hit by an unnecessary difference.
>
> 4) ... ?
>
> Are there downsides? I haven't come up with any interesting ones, but it
> wouldn't surprise me if someone else could.  I implemented this locally
> and the whole test suite passed without modification.
>
The only possible downside I can see is less control to force the
erasure of something to be Object. Not sure whether this will come up
though. So I think it's certainly worth trying. But I would generalize
it, in order to avoid making Object a special case:

 The erasure of a compound type T_1 with ... with T_n {R } is the first
T_i which is not a supertype of T_{i+1}, ..., T_n.

Cheers

On Sat, Dec 5, 2009 at 3:53 PM, martin odersky wrote:
> On Fri, Dec 4, 2009 at 10:01 PM, Paul Phillips wrote:
>> Proposal: The erasure of "Object with A" is "A" instead of "Object".
>>
>> Motivations:
>>
>> 1) Remove a bunch of checkcasts from bytecode.
>> 2) Generated bytecode easier to use from java.  Example:
>>
>>  def zipWithIndex = new Iterator[(A, Int)] { methods  }
>>
>> At present this generates at the bytecode level a method with return
>> type Object.  If you call it from java you will have to cast it to
>> Iterator.  Right now to get the right return type in the bytecode, every
>> method which creates one must declare it explicitly.
>>
>> 3) More robust binary compatibility: right now if you change something
>> from a trait to an abstract class, in situations like the above the
>> return type will flip from Object to the class.  There's no reason
>> traits and abstract classes need to behave differently here.  This would
>> break binary compat right now (and now is surely the time to do it) but
>> from this point forward people could switch between trait and abstract
>> class without being hit by an unnecessary difference.
>>
>> 4) ... ?
>>
>> Are there downsides? I haven't come up with any interesting ones, but it
>> wouldn't surprise me if someone else could.  I implemented this locally
>> and the whole test suite passed without modification.
>>
> The only possible downside I can see is less control to force the
> erasure of something to be Object. Not sure whether this will come up
> though. So I think it's certainly worth trying. But I would generalize
> it, in order to avoid making Object a special case:
>
>   The erasure of a compound type T_1 with ... with T_n {R } is the first
>   T_i which is not a supertype of T_{i+1}, ..., T_n.
>
I have to refine that. I think if some of the factors of a compound
type refers to a class (not a trait) which is not a superclass of any
of the other types, we should pick that type. I believe that's also
what Java does. I'll check in a spec & compiler change to do that.

Cheers