Bad initialization state for override lazy/traits

David,

This bug is fixed in trunk (duplicate of #1535). I ported it to the 2.7
branch and, in case there's a new 2.7 release, it will be there.

Here's an idea: backporting is a tedious but simple task that could be
taken over by someone in the community. It's a matter of spotting
important bug fixes and applying them to the maintenance branch, running
the tests and making sure nothing breaks. Not all bugs need to be
backported, of course, but this is the general idea. It would relieve a
burden on the team here and make people happier. There's an issue about
coordinating releases, so that person should work closely with the EPFL
team -- similar to how the Eclipse IDE and maven builds are handled .
What do others think?

iulian

David Pollak wrote:
> Folks,
>
> The following code:
>
> class One {
> lazy val a = "foo"
> }
>
> class Four extends One {
> override lazy val a = "baz"
> }
>
> trait Two {
> lazy val b = "bar"
> }
>
> class Three extends Four with Two {
> }
>
> val three = new Three
>
> println(three.b)
> println(three.a)
>
>
>
> Prints "null" while evaluating three.a.
>
> I've opened a ticket for
> it: https://lampsvn.epfl.ch/trac/scala/ticket/2463
>
> Any chance this could get fixed for 2.7.7 or is it just too late?
>
> Thanks,
>
> David
>
>

On Tue, Oct 13, 2009 at 12:58 AM, Iulian Dragos <iulian.dragos@epfl.ch> wrote:

David,

This bug is fixed in trunk (duplicate of #1535). I ported it to the 2.7 branch and, in case there's a new 2.7 release, it will be there.

Cool.  So will it be part of 2.7.7?  

Here's an idea: backporting  is a tedious but simple task that could be taken over by someone in the community. It's a matter of spotting important bug fixes and applying them to the maintenance branch, running the tests and making sure nothing breaks. Not all bugs need to be backported, of course, but this is the general idea. It would relieve a burden on the team here and make people happier. There's an issue about coordinating releases, so that person should work closely with the EPFL team -- similar to how the Eclipse IDE and maven builds are handled . What do others think?

I am all for it.  I have a standing offer to organize the folks (and contribute myself) for release engineering, backporting, and whatever other less palleteable tasks EPFL wants to offload.  I am all for helping the EPFL folks do what the do best and love doing best.  
Thanks,
David 

iulian

David Pollak wrote:

Folks,

The following code:

   class One {
     lazy val a = "foo"
   }

   class Four extends One {
     override lazy val a = "baz"
   }

   trait Two {
     lazy val b = "bar"
   }

   class Three extends Four with Two {
   }

   val three = new Three

   println(three.b)
   println(three.a)



Prints "null" while evaluating three.a.

I've opened a ticket for it: https://lampsvn.epfl.ch/trac/scala/ticket/2463

Any chance this could get fixed for 2.7.7 or is it just too late?

Thanks,

David

David Pollak wrote:
>
>
> On Tue, Oct 13, 2009 at 12:58 AM, Iulian Dragos > wrote:
>
> David,
>
> This bug is fixed in trunk (duplicate of #1535). I ported it to
> the 2.7 branch and, in case there's a new 2.7 release, it will be
> there.
>
>
> Cool. So will it be part of 2.7.7?

Yes, it will go into RC2.

>
>
>
> Here's an idea: backporting is a tedious but simple task that
> could be taken over by someone in the community. It's a matter of
> spotting important bug fixes and applying them to the maintenance
> branch, running the tests and making sure nothing breaks. Not all
> bugs need to be backported, of course, but this is the general
> idea. It would relieve a burden on the team here and make people
> happier. There's an issue about coordinating releases, so that
> person should work closely with the EPFL team -- similar to how
> the Eclipse IDE and maven builds are handled . What do others think?
>
>
> I am all for it. I have a standing offer to organize the folks (and
> contribute myself) for release engineering, backporting, and whatever
> other less palleteable tasks EPFL wants to offload. I am all for
> helping the EPFL folks do what the do best and love doing best.
I just heard about that from Martin, it's nice to see things converging.

iulian

>
> Thanks,
>
> David
>
>
>
> iulian
>
>
> David Pollak wrote:
>
> Folks,
>
> The following code:
>
> class One {
> lazy val a = "foo"
> }
>
> class Four extends One {
> override lazy val a = "baz"
> }
>
> trait Two {
> lazy val b = "bar"
> }
>
> class Three extends Four with Two {
> }
>
> val three = new Three
>
> println(three.b)
> println(three.a)
>
>
>
> Prints "null" while evaluating three.a.
>
> I've opened a ticket for it:
> https://lampsvn.epfl.ch/trac/scala/ticket/2463
>
> Any chance this could get fixed for 2.7.7 or is it just too late?
>
> Thanks,
>
> David
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
>
>
> --
> Iulian Dragos
> =============
> EPFL-IIF-LAMP 1
> INR 321 http://lamp.epfl.ch/~dragos
>
>
>
>