« Return to Thread: [scala] Constructor parameters for traits

Re: [scala] Constructor parameters for traits

by Marius Danciu-2 :: Rate this Message:

Reply to Author | View in Thread

Doesn't linearization help here ?

On Tue, Dec 2, 2008 at 8:58 PM, James Iry <jamesiry@...> wrote:
Diamond inheritance creates extra complexity.  Here's one example

trait Base(val msg : String}
trait Sub1 extends Base("hello")
trait Sub2 extends Base("goodbye")
Object Test extends Sub1 with Sub2
println(Test.msg) // hello?  goodbye? error?

There are ways for a language to let you resolve diamond inheritance.  But it does complicate things.


On Tue, Dec 2, 2008 at 9:17 AM, Sebastien Braun <sebb@...> wrote:
Hello, List.

I know that traits can not have constructor parameters, however I have not
been able to find out much about the rationale behind this restriction; my
google-fu fails me and the SLS is quiet on it (or, maybe, I just don't know
where to look for it).

For this scala code

> trait A {
>   System.out.println("Hello, World!")
> }
>
> class AImpl extends A

scalac will generate (something closely resembling) the following pseudo-Java:

> public interface A {}
>
> public class A$class {
>       public static void $init$(A $this) {
>               System.out.println("Hello, World!");
>       }
> }
>
> public class AImpl implements A {
>       public A() {
>               A$class.$init$(this);
>       }
> }

So, intuitively (and perhaps naïvely...), it seems to me that the compiler
should also be able to accept constructor parameters for traits:

> trait A(message: String) {
>       System.out.println(message)
> }

and just tack on the arguments to the $init$ method of the trait's
implementation class:

> public interface A {}
>
> public class A$class {
>       public static void $init$(A $this, String message) {
>               System.out.println(message);
>       }
> }

Is this a bad idea?

Cheers,

Sébastien


 « Return to Thread: [scala] Constructor parameters for traits