Why use List ?

Can you please ask this again on StackOverflow?
It's too good a question to stay buried in the mailing lists


On 15 May 2010 14:35, Daniel Degrandi <Daniel.Degrandi@uni-duesseldorf.de> wrote:

Hi Scalar's,

this might be a dumb question from someone who is quite new to Scala and is just learning coding functional style.
What are the advantages of using Lists over other collections like e.g. Seq's ?

I understand that Lists have a recursive structure and can be easily decomposed by pattern matching, but does this justify the excessive use of Lists in scala programs?
I performed several benchmarks with common methods found allover the scala collections, like map, filter, flatmap, foreach, etc.. Lists are significantly slower compared to e.g Arrays or Seq's

So it would be helpful for me to understand why and when I should use Lists.

Thank you

Daniel

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

lists are immutable, which means they are thread safe.

Daniel Degrandi schrieb:
> Hi Scalar's,
>
> this might be a dumb question from someone who is quite new to Scala
> and is just learning coding functional style.
> What are the advantages of using Lists over other collections like
> e.g. Seq's ?
>
> I understand that Lists have a recursive structure and can be easily
> decomposed by pattern matching, but does this justify the excessive
> use of Lists in scala programs?
> I performed several benchmarks with common methods found allover the
> scala collections, like map, filter, flatmap, foreach, etc.. Lists are
> significantly slower compared to e.g Arrays or Seq's
>
> So it would be helpful for me to understand why and when I should use
> Lists.
>
> Thank you
>
> Daniel
>

Not true. You still need proper synchronization if you want to pass a List from a thread to another (that's because :: contains vars - a compromise due to its particular handling of serialization). 
Dimitris
2010/5/15 HamsterofDeath <h-star@gmx.de>

lists are immutable, which means they are thread safe.

Daniel Degrandi schrieb:
> Hi Scalar's,
>
> this might be a dumb question from someone who is quite new to Scala
> and is just learning coding functional style.
> What are the advantages of using Lists over other collections like
> e.g. Seq's ?
>
> I understand that Lists have a recursive structure and can be easily
> decomposed by pattern matching, but does this justify the excessive
> use of Lists in scala programs?
> I performed several benchmarks with common methods found allover the
> scala collections, like map, filter, flatmap, foreach, etc.. Lists are
> significantly slower compared to e.g Arrays or Seq's
>
> So it would be helpful for me to understand why and when I should use
> Lists.
>
> Thank you
>
> Daniel
>

Now I'm scared. I need to use low level concurrency constructs to pass a list from one thread (or let's say thread-based actor) to another? Ouch.

Am 15.05.2010 um 17:44 schrieb Dimitris Andreou:

> Not true. You still need proper synchronization if you want to pass a List from a thread to another (that's because :: contains vars - a compromise due to its particular handling of serialization).
>
> Dimitris
>
> 2010/5/15 HamsterofDeath
> lists are immutable, which means they are thread safe.
>
> Daniel Degrandi schrieb:
> > Hi Scalar's,
> >
> > this might be a dumb question from someone who is quite new to Scala
> > and is just learning coding functional style.
> > What are the advantages of using Lists over other collections like
> > e.g. Seq's ?
> >
> > I understand that Lists have a recursive structure and can be easily
> > decomposed by pattern matching, but does this justify the excessive
> > use of Lists in scala programs?
> > I performed several benchmarks with common methods found allover the
> > scala collections, like map, filter, flatmap, foreach, etc.. Lists are
> > significantly slower compared to e.g Arrays or Seq's
> >
> > So it would be helpful for me to understand why and when I should use
> > Lists.
> >
> > Thank you
> >
> > Daniel
> >
>
>

really?? no way.... are you sure they are not just method-local variables used during construction?

Am 15.05.2010 um 16:44 schrieb Dimitris Andreou:

> Not true. You still need proper synchronization if you want to pass a List from a thread to another (that's because :: contains vars - a compromise due to its particular handling of serialization).
>
> Dimitris
>
> 2010/5/15 HamsterofDeath
> lists are immutable, which means they are thread safe.
>
> Daniel Degrandi schrieb:
> > Hi Scalar's,
> >
> > this might be a dumb question from someone who is quite new to Scala
> > and is just learning coding functional style.
> > What are the advantages of using Lists over other collections like
> > e.g. Seq's ?
> >
> > I understand that Lists have a recursive structure and can be easily
> > decomposed by pattern matching, but does this justify the excessive
> > use of Lists in scala programs?
> > I performed several benchmarks with common methods found allover the
> > scala collections, like map, filter, flatmap, foreach, etc.. Lists are
> > significantly slower compared to e.g Arrays or Seq's
> >
> > So it would be helpful for me to understand why and when I should use
> > Lists.
> >
> > Thank you
> >
> > Daniel
> >
>
>

I think some of the list methods internally used mutable data structures for performance reasons.
But List itself is immutable, and wasn't that changed with 2.8 anyway?

On 15 May 2010 16:44, Dimitris Andreou <jim.andreou@gmail.com> wrote:

Not true. You still need proper synchronization if you want to pass a List from a thread to another (that's because :: contains vars - a compromise due to its particular handling of serialization). 
Dimitris
2010/5/15 HamsterofDeath <h-star@gmx.de>

lists are immutable, which means they are thread safe.

Daniel Degrandi schrieb:
> Hi Scalar's,
>
> this might be a dumb question from someone who is quite new to Scala
> and is just learning coding functional style.
> What are the advantages of using Lists over other collections like
> e.g. Seq's ?
>
> I understand that Lists have a recursive structure and can be easily
> decomposed by pattern matching, but does this justify the excessive
> use of Lists in scala programs?
> I performed several benchmarks with common methods found allover the
> scala collections, like map, filter, flatmap, foreach, etc.. Lists are
> significantly slower compared to e.g Arrays or Seq's
>
> So it would be helpful for me to understand why and when I should use
> Lists.
>
> Thank you
>
> Daniel
>

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

On Saturday May 15 2010, Sciss wrote:
> Am 15.05.2010 um 16:44 schrieb Dimitris Andreou:
> > Not true. You still need proper synchronization if you want to pass
> > a List from a thread to another (that's because :: contains vars -
> > a compromise due to its particular handling of serialization).
> >
> > Dimitris
>
> really?? no way.... are you sure they are not just
> method-local variables used during construction?

From [1]:
-==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==-
405 @SerialVersionUID(0L - 8476791151983527571L)
406 final case class ::[B](private var hd: B, private[scala] var tl: List[B]) extends List[B] {
407 override def head : B = hd
408 override def tail : List[B] = tl
409 override def isEmpty: Boolean = false
410
411 import java.io._
//...
-==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==-

[1] 

Randall Schulz

There's nothing changing that var in Lists methods, though. I thought its only use was fast conversion of a ListBuffer into a List.

On Sat, May 15, 2010 at 12:44 PM, Dimitris Andreou <jim.andreou@gmail.com> wrote:

Not true. You still need proper synchronization if you want to pass a List from a thread to another (that's because :: contains vars - a compromise due to its particular handling of serialization). 
Dimitris
2010/5/15 HamsterofDeath <h-star@gmx.de>

lists are immutable, which means they are thread safe.

Daniel Degrandi schrieb:
> Hi Scalar's,
>
> this might be a dumb question from someone who is quite new to Scala
> and is just learning coding functional style.
> What are the advantages of using Lists over other collections like
> e.g. Seq's ?
>
> I understand that Lists have a recursive structure and can be easily
> decomposed by pattern matching, but does this justify the excessive
> use of Lists in scala programs?
> I performed several benchmarks with common methods found allover the
> scala collections, like map, filter, flatmap, foreach, etc.. Lists are
> significantly slower compared to e.g Arrays or Seq's
>
> So it would be helpful for me to understand why and when I should use
> Lists.
>
> Thank you
>
> Daniel
>

--
Daniel C. Sobral

I travel to the future all the time.

final case class ::[B](private var hd: B, private[scala] var tl: List[B]) extends List[B] {
That's trunk.

On Sat, May 15, 2010 at 1:21 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

I think some of the list methods internally used mutable data structures for performance reasons.
But List itself is immutable, and wasn't that changed with 2.8 anyway?

On 15 May 2010 16:44, Dimitris Andreou <jim.andreou@gmail.com> wrote:

Not true. You still need proper synchronization if you want to pass a List from a thread to another (that's because :: contains vars - a compromise due to its particular handling of serialization). 
Dimitris
2010/5/15 HamsterofDeath <h-star@gmx.de>

lists are immutable, which means they are thread safe.

Daniel Degrandi schrieb:
> Hi Scalar's,
>
> this might be a dumb question from someone who is quite new to Scala
> and is just learning coding functional style.
> What are the advantages of using Lists over other collections like
> e.g. Seq's ?
>
> I understand that Lists have a recursive structure and can be easily
> decomposed by pattern matching, but does this justify the excessive
> use of Lists in scala programs?
> I performed several benchmarks with common methods found allover the
> scala collections, like map, filter, flatmap, foreach, etc.. Lists are
> significantly slower compared to e.g Arrays or Seq's
>
> So it would be helpful for me to understand why and when I should use
> Lists.
>
> Thank you
>
> Daniel
>

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

--
Daniel C. Sobral

I travel to the future all the time.

There are a lot of methods in all those classes, so you can always find one which is not efficient for a particular class.
List excels at three methods: :: (prepend), head and tail. Algorithms that are implemented in terms of these three methods, and there are many such, cannot do better than to use List.
The rest is habit. I, for one, tend to use the abstract collection that more closely fits what I need: Traversable, Seq or IndexedSeq. But if I find myself using those three methods above, I switch to List.

On Sat, May 15, 2010 at 10:35 AM, Daniel Degrandi <Daniel.Degrandi@uni-duesseldorf.de> wrote:

Hi Scalar's,

this might be a dumb question from someone who is quite new to Scala and is just learning coding functional style.
What are the advantages of using Lists over other collections like e.g. Seq's ?

I understand that Lists have a recursive structure and can be easily decomposed by pattern matching, but does this justify the excessive use of Lists in scala programs?
I performed several benchmarks with common methods found allover the scala collections, like map, filter, flatmap, foreach, etc.. Lists are significantly slower compared to e.g Arrays or Seq's

So it would be helpful for me to understand why and when I should use Lists.

Thank you

Daniel

--
Daniel C. Sobral

I travel to the future all the time.

what's the point of having "immutable" collections if they are not thread-safe, then? i'm fairly shocked....

Am 15.05.2010 um 17:24 schrieb Daniel Sobral:

> final case class ::[B](private var hd: B, private[scala] var tl: List[B]) extends List[B] {
>
> That's trunk.
>
> On Sat, May 15, 2010 at 1:21 PM, Kevin Wright wrote:
> I think some of the list methods internally used mutable data structures for performance reasons.
>
> But List itself is immutable, and wasn't that changed with 2.8 anyway?
>
>
> On 15 May 2010 16:44, Dimitris Andreou wrote:
> Not true. You still need proper synchronization if you want to pass a List from a thread to another (that's because :: contains vars - a compromise due to its particular handling of serialization).
>
> Dimitris
>
> 2010/5/15 HamsterofDeath
>
> lists are immutable, which means they are thread safe.
>
> Daniel Degrandi schrieb:
> > Hi Scalar's,
> >
> > this might be a dumb question from someone who is quite new to Scala
> > and is just learning coding functional style.
> > What are the advantages of using Lists over other collections like
> > e.g. Seq's ?
> >
> > I understand that Lists have a recursive structure and can be easily
> > decomposed by pattern matching, but does this justify the excessive
> > use of Lists in scala programs?
> > I performed several benchmarks with common methods found allover the
> > scala collections, like map, filter, flatmap, foreach, etc.. Lists are
> > significantly slower compared to e.g Arrays or Seq's
> >
> > So it would be helpful for me to understand why and when I should use
> > Lists.
> >
> > Thank you
> >
> > Daniel
> >
>
>
>
>
>

No need to worry that much. I should have been more clear.
"If you store a List reference to a variable, and another thread sees that reference, and there is no happens-before relationship between the writer and the reader, the second may see the List instance in inconsistent state".
But that's not the way one typically exchanges objects between threads. If you use a BlockingQueue (which itself has sufficient internal synchronization), as e.g. actors' mailboxes, that's fine. That's one of the most common ways. If you would use a volatile variable for the scenario above, it would also be perfectly fine. Having a variable accessed by a reader and writer without any synchronization would be a data race anyway (most probably a bug by itself), and only such data races are affected by what I said.
By the way, ::'s fields could well be declared as vals instead of vars, it would just need a different serialization mechanism. 
Dimitris

2010/5/15 Sciss <contact@sciss.de>

what's the point of having "immutable" collections if they are not thread-safe, then? i'm fairly shocked....

Am 15.05.2010 um 17:24 schrieb Daniel Sobral:

> final case class ::[B](private var hd: B, private[scala] var tl: List[B]) extends List[B] {
>
> That's trunk.
>
> On Sat, May 15, 2010 at 1:21 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:
> I think some of the list methods internally used mutable data structures for performance reasons.
>
> But List itself is immutable, and wasn't that changed with 2.8 anyway?
>
>
> On 15 May 2010 16:44, Dimitris Andreou <jim.andreou@gmail.com> wrote:
> Not true. You still need proper synchronization if you want to pass a List from a thread to another (that's because :: contains vars - a compromise due to its particular handling of serialization).
>
> Dimitris
>
> 2010/5/15 HamsterofDeath <h-star@gmx.de>
>
> lists are immutable, which means they are thread safe.
>
> Daniel Degrandi schrieb:
> > Hi Scalar's,
> >
> > this might be a dumb question from someone who is quite new to Scala
> > and is just learning coding functional style.
> > What are the advantages of using Lists over other collections like
> > e.g. Seq's ?
> >
> > I understand that Lists have a recursive structure and can be easily
> > decomposed by pattern matching, but does this justify the excessive
> > use of Lists in scala programs?
> > I performed several benchmarks with common methods found allover the
> > scala collections, like map, filter, flatmap, foreach, etc.. Lists are
> > significantly slower compared to e.g Arrays or Seq's
> >
> > So it would be helpful for me to understand why and when I should use
> > Lists.
> >
> > Thank you
> >
> > Daniel
> >
>
>
>
>
>
> --
> Kevin Wright
>
> mail/google talk: kev.lee.wright@googlemail.com
> wave: kev.lee.wright@googlewave.com
> skype: kev.lee.wright
> twitter: @thecoda
>
>
>
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.

Oh, I guess you're right, ListBuffer usage is another reason (or "the" reason) for declaring those as vars, I had only checked List.scala.

2010/5/15 Daniel Sobral <dcsobral@gmail.com>

There's nothing changing that var in Lists methods, though. I thought its only use was fast conversion of a ListBuffer into a List.

On Sat, May 15, 2010 at 12:44 PM, Dimitris Andreou <jim.andreou@gmail.com> wrote:

Not true. You still need proper synchronization if you want to pass a List from a thread to another (that's because :: contains vars - a compromise due to its particular handling of serialization). 
Dimitris
2010/5/15 HamsterofDeath <h-star@gmx.de>

lists are immutable, which means they are thread safe.

Daniel Degrandi schrieb:
> Hi Scalar's,
>
> this might be a dumb question from someone who is quite new to Scala
> and is just learning coding functional style.
> What are the advantages of using Lists over other collections like
> e.g. Seq's ?
>
> I understand that Lists have a recursive structure and can be easily
> decomposed by pattern matching, but does this justify the excessive
> use of Lists in scala programs?
> I performed several benchmarks with common methods found allover the
> scala collections, like map, filter, flatmap, foreach, etc.. Lists are
> significantly slower compared to e.g Arrays or Seq's
>
> So it would be helpful for me to understand why and when I should use
> Lists.
>
> Thank you
>
> Daniel
>

--
Daniel C. Sobral

I travel to the future all the time.

Mutability is a function of your code. A ListBuffer can be very
immutable if I don't change it :). A plain List is an interfac with an
immutable contract. It could easily point to a mutable ListBuffer
though.
Its good use is to advertise to the world that your component doesn't
mess with the data it receives or vice-versa ;)

You can safely pass anything between threads as long as the threads
dont change it.

As for the actual List(1,2,3) - is a convenience from my pov, when you
don't care too much about what you're using...

Cheers.
Where there's thrteads, there be dragons!

On 5/15/10, Dimitris Andreou wrote:
> Oh, I guess you're right, ListBuffer usage is another reason (or "the"
> reason) for declaring those as vars, I had only checked List.scala.
>
> 2010/5/15 Daniel Sobral
>
>> There's nothing changing that var in Lists methods, though. I thought its
>> only use was fast conversion of a ListBuffer into a List.
>>
>>
>> On Sat, May 15, 2010 at 12:44 PM, Dimitris Andreou
>> wrote:
>>
>>> Not true. You still need proper synchronization if you want to pass a
>>> List
>>> from a thread to another (that's because :: contains vars - a compromise
>>> due
>>> to its particular handling of serialization).
>>>
>>> Dimitris
>>>
>>> 2010/5/15 HamsterofDeath
>>>
>>> lists are immutable, which means they are thread safe.
>>>>
>>>> Daniel Degrandi schrieb:
>>>> > Hi Scalar's,
>>>> >
>>>> > this might be a dumb question from someone who is quite new to Scala
>>>> > and is just learning coding functional style.
>>>> > What are the advantages of using Lists over other collections like
>>>> > e.g. Seq's ?
>>>> >
>>>> > I understand that Lists have a recursive structure and can be easily
>>>> > decomposed by pattern matching, but does this justify the excessive
>>>> > use of Lists in scala programs?
>>>> > I performed several benchmarks with common methods found allover the
>>>> > scala collections, like map, filter, flatmap, foreach, etc.. Lists are
>>>> > significantly slower compared to e.g Arrays or Seq's
>>>> >
>>>> > So it would be helpful for me to understand why and when I should use
>>>> > Lists.
>>>> >
>>>> > Thank you
>>>> >
>>>> > Daniel
>>>> >
>>>>
>>>>
>>>
>>
>>
>> --
>> Daniel C. Sobral
>>
>> I travel to the future all the time.
>>
>

2010/5/15 Razie <razvanc99@gmail.com>

Mutability is a function of your code. A ListBuffer can be very
immutable if I don't change it :). A plain List is an interfac with an
immutable contract. It could easily point to a mutable ListBuffer
though.
Its good use is to advertise to the world that your component doesn't
mess with the data it receives or vice-versa ;)

You can safely pass anything between threads as long as the threads
dont change it.

Not true, with the notable exception of state that is reachable through a path of final fields. See section 17.5 of JLS: http://java.sun.com/docs/books/jls/third_edition/html/memory.html#66562 Which is why List is affected. But anyway, since this only affects passing things between threads using data races (e.g., writing to a non-volatile variable and reading from it, without any synchronization between those), one can mostly ignore the issue.  

As for the actual List(1,2,3) - is a convenience from my pov, when you
don't care too much about what you're using...

Cheers.
Where there's thrteads, there be dragons!

Well, that's true :) 

On 5/15/10, Dimitris Andreou <jim.andreou@gmail.com> wrote:
> Oh, I guess you're right, ListBuffer usage is another reason (or "the"
> reason) for declaring those as vars, I had only checked List.scala.
>
> 2010/5/15 Daniel Sobral <dcsobral@gmail.com>
>
>> There's nothing changing that var in Lists methods, though. I thought its
>> only use was fast conversion of a ListBuffer into a List.
>>
>>
>> On Sat, May 15, 2010 at 12:44 PM, Dimitris Andreou
>> <jim.andreou@gmail.com>wrote:
>>
>>> Not true. You still need proper synchronization if you want to pass a
>>> List
>>> from a thread to another (that's because :: contains vars - a compromise
>>> due
>>> to its particular handling of serialization).
>>>
>>> Dimitris
>>>
>>> 2010/5/15 HamsterofDeath <h-star@gmx.de>
>>>
>>> lists are immutable, which means they are thread safe.
>>>>
>>>> Daniel Degrandi schrieb:
>>>> > Hi Scalar's,
>>>> >
>>>> > this might be a dumb question from someone who is quite new to Scala
>>>> > and is just learning coding functional style.
>>>> > What are the advantages of using Lists over other collections like
>>>> > e.g. Seq's ?
>>>> >
>>>> > I understand that Lists have a recursive structure and can be easily
>>>> > decomposed by pattern matching, but does this justify the excessive
>>>> > use of Lists in scala programs?
>>>> > I performed several benchmarks with common methods found allover the
>>>> > scala collections, like map, filter, flatmap, foreach, etc.. Lists are
>>>> > significantly slower compared to e.g Arrays or Seq's
>>>> >
>>>> > So it would be helpful for me to understand why and when I should use
>>>> > Lists.
>>>> >
>>>> > Thank you
>>>> >
>>>> > Daniel
>>>> >
>>>>
>>>>
>>>
>>
>>
>> --
>> Daniel C. Sobral
>>
>> I travel to the future all the time.
>>
>

--
Sent from my mobile device

On Sat, May 15, 2010 at 6:09 PM, Dimitris Andreou wrote:
> If you use a BlockingQueue (which itself has sufficient internal
> synchronization), as e.g. actors' mailboxes, that's fine. That's one of the
> most common ways. If you would use a volatile variable for the scenario
> above, it would also be perfectly fine.

I think you forgot to mention a very common case: if the List is used
in immutable classes (e.g. if the List is assigned to a val and it
doesn't escape the constructor). That is also safe. In other words, if
you stick to immutable classes yourself, you don't have to worry about
volatile, blocking queues or actor mailboxes.

Having said that, I wonder if the decision to make List not
thread-safe according to the JMM was done consciously or as an
oversight.

Best,
Ismael

2010/5/15 Ismael Juma <mlists@juma.me.uk>

On Sat, May 15, 2010 at 6:09 PM, Dimitris Andreou <jim.andreou@gmail.com> wrote:
> If you use a BlockingQueue (which itself has sufficient internal
> synchronization), as e.g. actors' mailboxes, that's fine. That's one of the
> most common ways. If you would use a volatile variable for the scenario
> above, it would also be perfectly fine.

I think you forgot to mention a very common case: if the List is used
in immutable classes (e.g. if the List is assigned to a val and it
doesn't escape the constructor). That is also safe. In other words, if
you stick to immutable classes yourself, you don't have to worry about
volatile, blocking queues or actor mailboxes.

Yes, you are right. I also used a much stricter phrase than needed (state reachable through "a path of final fields"), indeed, for unchanged state, just the root field needs to be final. E.g., if one wants to pass an (effectively) immutable object around via a data race (assuming there is a reason), which does not necessarily consist of finals, he can always pass instead a wrapper with a final field referencing the to-be-passed object, and that's always safe.
Regards, Dimitris

Having said that, I wonder if the decision to make List not
thread-safe according to the JMM was done consciously or as an
oversight.

Best,
Ismael

this is a trait i want to use to override the method canBeRepaired in
several classes

trait Repairable {
override def canBeRepaired = true
}

the compiler tells me that i need to use a "third member", but doesn't
give an example. what does it from from me?

I don't know how to solve it, but here's one way to reproduce the problem.

scala> trait Repairable {
| self: { def canBeRepaired: Boolean} =>
| override def canBeRepaired = true
| }
defined trait Repairable

scala> trait R1 { def canBeRepaired: Boolean = false }
defined trait R1

scala> new R1 with Repairable
:8: error: overriding method canBeRepaired in trait R1 of
type => Boolean;
method canBeRepaired in trait Repairable of type => Boolean cannot
override a concrete member
without a third member that's overridden by both (this rule is
designed to prevent ``accidental overrides'')
new R1 with Repairable
^

-jason

On Sat, May 15, 2010 at 10:07 PM, HamsterofDeath wrote:
> this is a trait i want to use to override the method canBeRepaired in
> several classes
>
> trait Repairable {
>  override def canBeRepaired = true
> }
>
> the compiler tells me that i need to use a "third member", but doesn't
> give an example. what does it from from me?
>

even better:
 scala> trait Repairable {
      |   self: ClassWithMethodBeingOverridden =>
      |   override def canBeRepaired = true
      | }



On 15 May 2010 21:49, Jason Zaugg <jzaugg@gmail.com> wrote:

I don't know how to solve it, but here's one way to reproduce the problem.

 scala> trait Repairable {
      |   self: { def canBeRepaired: Boolean} =>
      |   override def canBeRepaired = true
      | }
 defined trait Repairable

 scala> trait R1 { def canBeRepaired: Boolean = false }
 defined trait R1

 scala> new R1 with Repairable
 <console>:8: error: overriding method canBeRepaired in trait R1 of
type => Boolean;
  method canBeRepaired in trait Repairable of type => Boolean cannot
override a concrete member
  without a third member that's overridden by both (this rule is
designed to prevent ``accidental overrides'')
        new R1 with Repairable
          ^

-jason


On Sat, May 15, 2010 at 10:07 PM, HamsterofDeath <h-star@gmx.de> wrote:
> this is a trait i want to use to override the method canBeRepaired in
> several classes
>
> trait Repairable {
>  override def canBeRepaired = true
> }
>
> the compiler tells me that i need to use a "third member", but doesn't
> give an example. what does it from from me?
>

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

Hmm, this looks like a bug to me. Shouldn't the mixin composition succeed at the last line?  Might be the interaction between structural types and self types.

Donna

On Sat, May 15, 2010 at 10:49 PM, Jason Zaugg <jzaugg@gmail.com> wrote:

I don't know how to solve it, but here's one way to reproduce the problem.

 scala> trait Repairable {
      |   self: { def canBeRepaired: Boolean} =>
      |   override def canBeRepaired = true
      | }
 defined trait Repairable

 scala> trait R1 { def canBeRepaired: Boolean = false }
 defined trait R1

 scala> new R1 with Repairable
 <console>:8: error: overriding method canBeRepaired in trait R1 of
type => Boolean;
  method canBeRepaired in trait Repairable of type => Boolean cannot
override a concrete member
  without a third member that's overridden by both (this rule is
designed to prevent ``accidental overrides'')
        new R1 with Repairable
          ^

-jason


On Sat, May 15, 2010 at 10:07 PM, HamsterofDeath <h-star@gmx.de> wrote:
> this is a trait i want to use to override the method canBeRepaired in
> several classes
>
> trait Repairable {
>  override def canBeRepaired = true
> }
>
> the compiler tells me that i need to use a "third member", but doesn't
> give an example. what does it from from me?
>

Yep, that's probably what he wants.

I took the vague "override the method canBeRepaired in several
classes" in the broadest literal sense.

-jason

On Sun, May 16, 2010 at 12:01 AM, Kevin Wright
wrote:
> even better:
>  scala> trait Repairable {
>       |   self: ClassWithMethodBeingOverridden =>
>       |   override def canBeRepaired = true
>       | }
>

the situation is:

trait Repairable {
def canBeRepaired = true
}

class building {
def canBeRepaired = false // default
}

class OneOfManySubClasses extends building with Repairable {
}

there are several repairable buildings and several unrepairable. i
wanted to use the trait to override canBeRepaired. yes, i could simply
override the method itself in any subclass, but then i would have to
change every impementation of canBeRepaired if the logic changes instead
of only one in my trait

Jason Zaugg schrieb:
> Yep, that's probably what he wants.
>
> I took the vague "override the method canBeRepaired in several
> classes" in the broadest literal sense.
>
> -jason
>
> On Sun, May 16, 2010 at 12:01 AM, Kevin Wright
> wrote:
>
>> even better:
>> scala> trait Repairable {
>> | self: ClassWithMethodBeingOverridden =>
>> | override def canBeRepaired = true
>> | }
>>
>>
>
>

On Sun, May 16, 2010 at 8:46 AM, HamsterofDeath <h-star@gmx.de> wrote:

the situation is:

trait Repairable {
  def canBeRepaired = true
}

class building {
  def canBeRepaired = false // default
}

class OneOfManySubClasses extends building with Repairable {
}

there are several repairable buildings and several unrepairable. i
wanted to use the trait to override canBeRepaired. yes, i could simply
override the method itself in any subclass, but then i would have to
change every impementation of canBeRepaired if the logic changes instead
of only one in my trait

It won't work this way. The problem is that the Scala compiler has no way of verifying that this was not done by accident, and Scala has checks against such accidental overrides. In practice, this makes sense because instead of one method you might have hundreds of methods in the class and in the trait, many of them inherited from elsewhere. So having some safety measures against accidental overrides is quite useful. What you need to do is create a third trait from which both Repairable and building inherit:

trait MayBeRepairable {
  def canBeRepaired
}

class Building extends MayBeRepairable {
  def canBeRepaired = false
}

trait Repairable extends MayBeRepairable {
  def canBeRepaaied = true
}

Building with Repairable


Hope this helps

 -- Martin
 

that's exactly what i needed. thx great master :)

martin odersky schrieb:
>
> On Sun, May 16, 2010 at 8:46 AM, HamsterofDeath > wrote:
>
> the situation is:
>
> trait Repairable {
> def canBeRepaired = true
> }
>
> class building {
> def canBeRepaired = false // default
> }
>
> class OneOfManySubClasses extends building with Repairable {
> }
>
> there are several repairable buildings and several unrepairable. i
> wanted to use the trait to override canBeRepaired. yes, i could simply
> override the method itself in any subclass, but then i would have to
> change every impementation of canBeRepaired if the logic changes
> instead
> of only one in my trait
>
> It won't work this way. The problem is that the Scala compiler has no
> way of verifying that this was not done by accident, and Scala has
> checks against such accidental overrides. In practice, this makes
> sense because instead of one method you might have hundreds of methods
> in the class and in the trait, many of them inherited from elsewhere.
> So having some safety measures against accidental overrides is quite
> useful. What you need to do is create a third trait from which both
> Repairable and building inherit:
>
> trait MayBeRepairable {
> def canBeRepaired
> }
>
> class Building extends MayBeRepairable {
> def canBeRepaired = false
> }
>
> trait Repairable extends MayBeRepairable {
> def canBeRepaaied = true
> }
>
> Building with Repairable
>
>
> Hope this helps
>