This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Syntax for Early Definitions

17 replies
Anders Bach Nielsen
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.

Hey All

We are currently at LAMP working on updating the definitions of early
initialisers. These are currently described in section 5.1.6 in the SLS,
however this update involves a lot of changes to the syntax and the
semantics of early initialization of members. The thing we what to put
to a debate is the syntax for this.

Currently the syntax is like:

trait T {
val x:String
val y = "bar" + x
}

class Foo extends {
val x = "baz"
} with T

To be able to properly initialize the trait T the value of x in Foo has
to be evaluated before the template of T is evaluated. We would like to
get rid of this syntax for the following reasons:

- a class can occur after a "with" (imagine T was a class).
- one would usually expect a type after an "extends"
- it is only an early block if there is a "with" afterwards:

class Foo extends { ... }

is actually equivalent to

class Foo { ... }

One proposed syntax is:

trait T {
val x:String
val y = "bar" + x
}

class Foo preInit {
val x = "baz"
} extends T

Here we mark the early initializer block with the preInit keyword. We
are not happy with that for two reasons:

- we'd like to avoid camel case keywords (suggestions for other keywords?)
- consequently, anonymous class instantiations would look like this:
preInit { ... } new T { ... }
It would be better to have the "new" at the begnning.

There is one more thing to consider. We are going to add constructor
parameters for traits in the future, which will be implemented with the
new early initializers. Suppose we have:

trait T1(t1: Int)
trait T2(t2: Int)
class A(a: Int) extends T1(a*2) with T2(-a)

In short, the order of evaluation would be

1.) evaluate constructor arguments for A
2.) evaluate early initializers of A (not present above)
3.) evaluate trait arguments bottom-up in the class linearization, i.e.
right to left syntactically
4.) call super constructor
5.) evaluate templates of base traits top-down in class linearization.

The relevant parts are 1-3. It might be more natural to have the early
initializers after the trait list, or, close to the template body. This
led us to the following syntax:

trait T {
val x:String
val y = "baz" + x
}

class Foo extends T {
val x = "baz"
super
// normal template statements
}

Here the early initializers and normal template statements are put
together in the same block and separated by the super keyword. This will
not introduce a new keyword, but there is still the issue that early
initializers are evaluated under different conditions than the other
template statements.

Considering the points above, does anyone have syntax suggestions for
the new early initializers?

Anders & Ingo

extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: Syntax for Early Definitions

On Wed, Dec 17, 2008 at 04:39:15PM +0100, Anders Bach Nielsen wrote:
> There is one more thing to consider. We are going to add constructor
> parameters for traits in the future, which will be implemented with the
> new early initializers. Suppose we have:
>
> trait T1(t1: Int)
> trait T2(t2: Int)
> class A(a: Int) extends T1(a*2) with T2(-a)

How is this to be evaluated if e.g. T1(t1: Int) extends T2(t1*3) ?

milessabin
Joined: 2008-08-11,
User offline. Last seen 33 weeks 3 days ago.
Re: Syntax for Early Definitions

On Wed, Dec 17, 2008 at 3:39 PM, Anders Bach Nielsen
wrote:
> Considering the points above, does anyone have syntax suggestions for
> the new early initializers?

Similiar to your preInit variant, but with a rename and shuffle,

trait T {
val x:String
val y = "baz" + x
}

class Foo super {
val x = "baz"
} extends {
...
}

new T super { ... } extends { ... }

Cheers,

Miles

imaier
Joined: 2008-07-01,
User offline. Last seen 23 weeks 2 days ago.
Re: Syntax for Early Definitions

Paul Phillips wrote:
> On Wed, Dec 17, 2008 at 04:39:15PM +0100, Anders Bach Nielsen wrote:
>> There is one more thing to consider. We are going to add constructor
>> parameters for traits in the future, which will be implemented with the
>> new early initializers. Suppose we have:
>>
>> trait T1(t1: Int)
>> trait T2(t2: Int)
>> class A(a: Int) extends T1(a*2) with T2(-a)
>
> How is this to be evaluated if e.g. T1(t1: Int) extends T2(t1*3) ?
>

I suppose you mean

trait T1(t1: Int) extends T2(t1*3)

That means that t1*3 is evaluated some time after t1. Please, don't let
this get into a discussion about trait parameters. That is a separate
issue we will discuss when we are ready.

Thanks,
Ingo

Lauri Alanko
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Syntax for Early Definitions

On Wed, Dec 17, 2008 at 04:39:15PM +0100, Anders Bach Nielsen wrote:
> There is one more thing to consider. We are going to add constructor
> parameters for traits in the future, which will be implemented with the
> new early initializers. Suppose we have:
>
> trait T1(t1: Int)
> trait T2(t2: Int)
> class A(a: Int) extends T1(a*2) with T2(-a)

If this is just going to be some nifty syntax for early initializers,
i.e. if t1 and t2 are still just ordinary members whose names occupy
the common member namespace and can hence conflict, then please
indicate this by requiring a "val" in front of the constructor parameter.

For the early initializer syntax, I'd prefer to have the early
initializers syntactically _after_ the list of superclasses, even
though they are initialized earlier. Some keyword is good to have to
distinguish the early initializers, but introducing new ones should be
avoided.

Say, how about "for super"? After all, the early initializers are
meant to provide values _for_ the superclass initializers. They could
even be declared in the template body itself. So:

trait T {
val x:String
val y = "bar" + x
}

class Foo extends T {
for super val x = "baz"
}

So we'd get rid of the EarlyDefs in the template, and add

TemplateStat ::= 'for' 'super' EarlyDef

perhaps with the additional constraint that all early initializers
must precede non-early PatVarDefs. (I'm not sure about FunDefs,
though. Why couldn't early initializers use functions defined in the
template body? It's not allowed for constructor arguments at the
moment for some reason.)

Lauri

imaier
Joined: 2008-07-01,
User offline. Last seen 23 weeks 2 days ago.
Re: Syntax for Early Definitions

Miles Sabin wrote:
> On Wed, Dec 17, 2008 at 3:39 PM, Anders Bach Nielsen
> wrote:
>> Considering the points above, does anyone have syntax suggestions for
>> the new early initializers?
>
> Similiar to your preInit variant, but with a rename and shuffle,
>
> trait T {
> val x:String
> val y = "baz" + x
> }
>
> class Foo super {
> val x = "baz"
> } extends {
> ...
> }
>
> new T super { ... } extends { ... }

The "new" in an anonymous instance creation takes the role of "extends"
in a class declaration because you are extending a class anonymously.
With the proposal above, it gets mixed up and it actually introduces
extends in a new expression. In short, you cannot write

new T extends { ... }

so you should not be able to write

new T super { ... } extends { ... }

Ingo

>
> Cheers,
>
>
> Miles
>

milessabin
Joined: 2008-08-11,
User offline. Last seen 33 weeks 3 days ago.
Re: Syntax for Early Definitions

On Wed, Dec 17, 2008 at 4:40 PM, Ingo Maier wrote:
> In short, you cannot write
>
> new T extends { ... }

You can't now, but it's not entirely clear to me why that couldn't be
changed ...

Cheers,

Miles

imaier
Joined: 2008-07-01,
User offline. Last seen 23 weeks 2 days ago.
Re: Syntax for Early Definitions

Miles Sabin wrote:
> On Wed, Dec 17, 2008 at 4:40 PM, Ingo Maier wrote:
>> In short, you cannot write
>>
>> new T extends { ... }
>
> You can't now, but it's not entirely clear to me why that couldn't be
> changed ...

It complicates the syntax and further adds an exception: you cannot have
a class after the extends here.

Ingo

>
> Cheers,
>
>
> Miles
>

imaier
Joined: 2008-07-01,
User offline. Last seen 23 weeks 2 days ago.
Re: Syntax for Early Definitions

Lauri Alanko wrote:
>
> Say, how about "for super"? After all, the early initializers are
> meant to provide values _for_ the superclass initializers. They could
> even be declared in the template body itself. So:
>
> trait T {
> val x:String
> val y = "bar" + x
> }
>
> class Foo extends T {
> for super val x = "baz"
> }

Interesting. It feels a bit strange to me to have a for here. It feels
also strange to have a two word modifier. I know, we already have
abstract override, but I don't like that either :)

Anyways, such early defs should always precede non-early defs as you
mentioned. That's mainly because early members are only allowed to
access preceding early members. That was one of the reasons for the
syntax with the separating super in the middle of the body.

>
> So we'd get rid of the EarlyDefs in the template, and add
>
> TemplateStat ::= 'for' 'super' EarlyDef
>
> perhaps with the additional constraint that all early initializers
> must precede non-early PatVarDefs. (I'm not sure about FunDefs,
> though. Why couldn't early initializers use functions defined in the
> template body?

Because methods can use other non-early members. It might be possible to
add early methods defs with similar restrictions as early fields but I
don't know whether anyone has really thought about that.

Ingo

>
>
> Lauri
>

Viktor Klang
Joined: 2008-12-17,
User offline. Last seen 1 year 27 weeks ago.
Re: Syntax for Early Definitions

I don't really like the idea, but if you're going to use a word for it, how about "eager"?

On Wed, Dec 17, 2008 at 6:22 PM, Ingo Maier <ingo [dot] maier [at] epfl [dot] ch> wrote:
Lauri Alanko wrote:

Say, how about "for super"? After all, the early initializers are
meant to provide values _for_ the superclass initializers. They could
even be declared in the template body itself. So:

trait T {
 val x:String
 val y = "bar" + x
}

class Foo extends T {
 for super val x = "baz"
}
Interesting. It feels a bit strange to me to have a for here. It feels also strange to have a two word modifier. I know, we already have abstract override, but I don't like that either :)

Anyways, such early defs should always precede non-early defs as you mentioned. That's mainly because early members are only allowed to access preceding early members. That was one of the reasons for the syntax with the separating super in the middle of the body.



So we'd get rid of the EarlyDefs in the template, and add
TemplateStat ::= 'for' 'super' EarlyDef

perhaps with the additional constraint that all early initializers
must precede non-early PatVarDefs. (I'm not sure about FunDefs,
though. Why couldn't early initializers use functions defined in the
template body?
Because methods can use other non-early members. It might be possible to add early methods defs with similar restrictions as early fields but I don't know whether anyone has really thought about that.

Ingo



Lauri





--
Viktor Klang
Senior Systems Analyst

Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
Re: Syntax for Early Definitions

trait Foo {
val x:String
val y = "baz"
}

class X with {
val x = "o hai"
} extends Foo {
...
}

Yes, it repurposes with. However it seems to read better in my mind.
I know it's not a class, and perhaps that it is defined before Foo.

Sent from my iPhone

On Dec 17, 2008, at 11:06 AM, "Miles Sabin"
wrote:

> On Wed, Dec 17, 2008 at 3:39 PM, Anders Bach Nielsen
> wrote:
>> Considering the points above, does anyone have syntax suggestions for
>> the new early initializers?
>
> Similiar to your preInit variant, but with a rename and shuffle,
>
> trait T {
> val x:String
> val y = "baz" + x
> }
>
> class Foo super {
> val x = "baz"
> } extends {
> ...
> }
>
> new T super { ... } extends { ... }
>
> Cheers,
>
>
> Miles

Meredith Gregory
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Syntax for Early Definitions
Josh, et al,

+1 for 'with'; however i'd rather see it after

trait Foo {
  val x:String
  val y = "baz"
}

class X extends Foo {
 ...
} with {
   val x = "o hai"
}

Just out of curiousity, how does this work in the multiple trait case?

trait Foo1 {
  val x:String
  val y1 = "one"
}

trait Foo2 {
  val x:String
  val y2 = "two"
}
...

trait FooN {
  val x:String
  val yN = "N"
}
class X extends Foo1 with ... FooN {
 ...
} ????

Best wishes,

--greg

On Wed, Dec 17, 2008 at 10:50 AM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:
trait Foo {
 val x:String
 val y = "baz"
}

class X with {
 val x = "o hai"
} extends Foo {
 ...
}

Yes, it repurposes with.  However it seems to read better in my mind.  I know it's not a class, and perhaps that it is defined before Foo.

Sent from my iPhone

On Dec 17, 2008, at 11:06 AM, "Miles Sabin" <miles [at] milessabin [dot] com> wrote:

On Wed, Dec 17, 2008 at 3:39 PM, Anders Bach Nielsen
<andersbach [dot] nielsen [at] epfl [dot] ch> wrote:
Considering the points above, does anyone have syntax suggestions for
the new early initializers?

Similiar to your preInit variant, but with a rename and shuffle,

 trait T {
  val x:String
  val y = "baz" + x
 }

 class Foo super {
  val x = "baz"
 } extends {
  ...
 }

 new T super { ... } extends { ... }

Cheers,


Miles



--
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com
Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
Re: Syntax for Early Definitions
class X with {  val x = "o hai"} extends Foo1 with Foo2 ... with FooN {...}
I think that's why it belongs at the beginning (plus it's "first" initialized?)

Sent from my iPhone
On Dec 17, 2008, at 2:24 PM, "Meredith Gregory" <lgreg [dot] meredith [at] gmail [dot] com> wrote:

Josh, et al,

+1 for 'with'; however i'd rather see it after

trait Foo {
  val x:String
  val y = "baz"
}

class X extends Foo {
 ...
} with {
   val x = "o hai"
}

Just out of curiousity, how does this work in the multiple trait case?

trait Foo1 {
  val x:String
  val y1 = "one"
}

trait Foo2 {
  val x:String
  val y2 = "two"
}
...

trait FooN {
  val x:String
  val yN = "N"
}
class X extends Foo1 with ... FooN {
 ...
} ????

Best wishes,

--greg

On Wed, Dec 17, 2008 at 10:50 AM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com (joshua [dot] suereth [at] gmail [dot] com" rel="nofollow">joshua [dot] suereth [at] gmail [dot] com)> wrote:
trait Foo {
 val x:String
 val y = "baz"
}

class X with {
 val x = "o hai"
} extends Foo {
 ...
}

Yes, it repurposes with.  However it seems to read better in my mind.  I know it's not a class, and perhaps that it is defined before Foo.

Sent from my iPhone

On Dec 17, 2008, at 11:06 AM, "Miles Sabin" <miles [at] milessabin [dot] com (miles [at] milessabin [dot] com" rel="nofollow">miles [at] milessabin [dot] com)> wrote:

On Wed, Dec 17, 2008 at 3:39 PM, Anders Bach Nielsen
<andersbach [dot] nielsen [at] epfl [dot] ch> wrote:
Considering the points above, does anyone have syntax suggestions for
the new early initializers?

Similiar to your preInit variant, but with a rename and shuffle,

 trait T {
  val x:String
  val y = "baz" + x
 }

 class Foo super {
  val x = "baz"
 } extends {
  ...
 }

 new T super { ... } extends { ... }

Cheers,


Miles



--
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com
Meredith Gregory
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Syntax for Early Definitions
Josh,

Beginning or end does not address the issue i was raising about multiplicity. At the end of the day beginning or end is merely about whether you like

let p = v in e

or

e where p = v

The problem is associating the calculation with the corresponding trait.

Best wishes,

--greg

On Wed, Dec 17, 2008 at 11:31 AM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:
class X with {  val x = "o hai" } extends Foo1 with Foo2 ... with FooN {...}
I think that's why it belongs at the beginning (plus it's "first" initialized?)

Sent from my iPhone
On Dec 17, 2008, at 2:24 PM, "Meredith Gregory" <lgreg [dot] meredith [at] gmail [dot] com> wrote:

Josh, et al,

+1 for 'with'; however i'd rather see it after

trait Foo {
  val x:String
  val y = "baz"
}

class X extends Foo {
 ...
} with {
   val x = "o hai"
}

Just out of curiousity, how does this work in the multiple trait case?

trait Foo1 {
  val x:String
  val y1 = "one"
}

trait Foo2 {
  val x:String
  val y2 = "two"
}
...

trait FooN {
  val x:String
  val yN = "N"
}
class X extends Foo1 with ... FooN {
 ...
} ????

Best wishes,

--greg

On Wed, Dec 17, 2008 at 10:50 AM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] comjoshua [dot] suereth [at] gmail [dot] com> wrote:
trait Foo {
 val x:String
 val y = "baz"
}

class X with {
 val x = "o hai"
} extends Foo {
 ...
}

Yes, it repurposes with.  However it seems to read better in my mind.  I know it's not a class, and perhaps that it is defined before Foo.

Sent from my iPhone

On Dec 17, 2008, at 11:06 AM, "Miles Sabin" <miles [at] milessabin [dot] commiles [at] milessabin [dot] com> wrote:

On Wed, Dec 17, 2008 at 3:39 PM, Anders Bach Nielsen
<andersbach [dot] nielsen [at] epfl [dot] ch> wrote:
Considering the points above, does anyone have syntax suggestions for
the new early initializers?

Similiar to your preInit variant, but with a rename and shuffle,

 trait T {
  val x:String
  val y = "baz" + x
 }

 class Foo super {
  val x = "baz"
 } extends {
  ...
 }

 new T super { ... } extends { ... }

Cheers,


Miles



--
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com



--
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com
Alex Cruise
Joined: 2008-12-17,
User offline. Last seen 2 years 26 weeks ago.
Re: Syntax for Early Definitions

Meredith Gregory wrote:
> Just out of curiousity, how does this work in the multiple trait case?
How about this? Unfortunately it breaks the symmetry between lexically
"earlier" syntax and early initialization, but I like it:

class X [extends Blah] {
// ...
} with Foo1 {
// ...
} with Foo2 {
// ...
}

-0xe1a

imaier
Joined: 2008-07-01,
User offline. Last seen 23 weeks 2 days ago.
Re: Syntax for Early Definitions

I don't quite see what you are up to with your example. If you want to
initialze the x early, then why not just do it?

Ingo

Meredith Gregory wrote:
> Josh, et al,
>
> +1 for 'with'; however i'd rather see it after
>
> trait Foo {
> val x:String
> val y = "baz"
> }
>
> class X extends Foo {
> ...
> } with {
> val x = "o hai"
> }
>
> Just out of curiousity, how does this work in the multiple trait case?
>
> trait Foo1 {
> val x:String
> val y1 = "one"
> }
>
> trait Foo2 {
> val x:String
> val y2 = "two"
> }
>
> ...
>
> trait FooN {
> val x:String
> val yN = "N"
> }
>
> class X extends Foo1 with ... FooN {
> ...
> } ????
>
> Best wishes,
>
> --greg
>
> On Wed, Dec 17, 2008 at 10:50 AM, Josh Suereth > wrote:
>
> trait Foo {
>
> val x:String
> val y = "baz"
> }
>
> class X with {
> val x = "o hai"
> } extends Foo {
> ...
> }
>
> Yes, it repurposes with. However it seems to read better in my
> mind. I know it's not a class, and perhaps that it is defined
> before Foo.
>
> Sent from my iPhone
>
>
> On Dec 17, 2008, at 11:06 AM, "Miles Sabin" > wrote:
>
> On Wed, Dec 17, 2008 at 3:39 PM, Anders Bach Nielsen
> wrote:
>
> Considering the points above, does anyone have syntax
> suggestions for
> the new early initializers?
>
>
> Similiar to your preInit variant, but with a rename and shuffle,
>
> trait T {
> val x:String
> val y = "baz" + x
> }
>
> class Foo super {
> val x = "baz"
> } extends {
> ...
> }
>
> new T super { ... } extends { ... }
>
> Cheers,
>
>
> Miles
>
>
>
>

Jan Lohre
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Syntax for Early Definitions
+1 for
1. doing things inside the normal class body
and
2. not introducing new keywords

2008/12/17 Lauri Alanko <la [at] iki [dot] fi>
On Wed, Dec 17, 2008 at 04:39:15PM +0100, Anders Bach Nielsen wrote:
> There is one more thing to consider. We are going to add constructor
> parameters for traits in the future, which will be implemented with the
> new early initializers. Suppose we have:
>
> trait T1(t1: Int)
> trait T2(t2: Int)
> class A(a: Int) extends T1(a*2) with T2(-a)

If this is just going to be some nifty syntax for early initializers,
i.e. if t1 and t2 are still just ordinary members whose names occupy
the common member namespace and can hence conflict, then please
indicate this by requiring a "val" in front of the constructor parameter.

For the early initializer syntax, I'd prefer to have the early
initializers syntactically _after_ the list of superclasses, even
though they are initialized earlier. Some keyword is good to have to
distinguish the early initializers, but introducing new ones should be
avoided.

Say, how about "for super"? After all, the early initializers are
meant to provide values _for_ the superclass initializers. They could
even be declared in the template body itself. So:

trait T {
 val x:String
 val y = "bar" + x
}

class Foo extends T {
 for super val x = "baz"
}

So we'd get rid of the EarlyDefs in the template, and add

TemplateStat ::= 'for' 'super' EarlyDef

perhaps with the additional constraint that all early initializers
must precede non-early PatVarDefs. (I'm not sure about FunDefs,
though. Why couldn't early initializers use functions defined in the
template body? It's not allowed for constructor arguments at the
moment for some reason.)


Lauri

Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
Re: Syntax for Early Definitions
Ah ok.  I was under the assumption that the "pre initializer block" happened before all traits and was used by all traits.  Which would mean no need to associate with any specific trait.  I believe there's an algorithm definition earlier describing this.
 
How would a per-trait "pre initializer block" look/act?  Wouldn't this bring back the deadly diamond issues of full blown multiple inheritence?
 
On Dec 17, 2008, at 2:59 PM, "Meredith Gregory" <lgreg [dot] meredith [at] gmail [dot] com> wrote:
 
 
Josh,

Beginning or end does not address the issue i was raising about multiplicity. At the end of the day beginning or end is merely about whether you like

let p = v in e

or

e where p = v

The problem is associating the calculation with the corresponding trait.

Best wishes,

--greg

On Wed, Dec 17, 2008 at 11:31 AM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:
class X with {
  val x = "o hai"
} extends Foo1 with Foo2 ... with FooN {
...
}
 
I think that's why it belongs at the beginning (plus it's "first" initialized?)

Sent from my iPhone
 

On Dec 17, 2008, at 2:24 PM, "Meredith Gregory" <lgreg [dot] meredith [at] gmail [dot] com> wrote:
 
 
Josh, et al,

+1 for 'with'; however i'd rather see it after

trait Foo {
  val x:String
  val y = "baz"
}
class X extends Foo {
 ...
} with {
   val x = "o hai"
}

Just out of curiousity, how does this work in the multiple trait case?

trait Foo1 {
  val x:String
  val y1 = "one"
}

trait Foo2 {
  val x:String
  val y2 = "two"
}

...

trait FooN {
  val x:String
  val yN = "N"
}
class X extends Foo1 with ... FooN {
 ...
} ????

Best wishes,

--greg

On Wed, Dec 17, 2008 at 10:50 AM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:
trait Foo {

 val x:String
 val y = "baz"
}
class X with {
 val x = "o hai"
} extends Foo {
 ...
}

Yes, it repurposes with.  However it seems to read better in my mind.  I know it's not a class, and perhaps that it is defined before Foo.

Sent from my iPhone
 


On Dec 17, 2008, at 11:06 AM, "Miles Sabin" <miles [at] milessabin [dot] com> wrote:

On Wed, Dec 17, 2008 at 3:39 PM, Anders Bach Nielsen
<andersbach [dot] nielsen [at] epfl [dot] ch> wrote:
Considering the points above, does anyone have syntax suggestions for
the new early initializers?

Similiar to your preInit variant, but with a rename and shuffle,

 trait T {
  val x:String
  val y = "baz" + x
 }

 class Foo super {
  val x = "baz"
 } extends {
  ...
 }

 new T super { ... } extends { ... }

Cheers,


Miles



--
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com



--
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland