Comments on Programming Scala

Comment on 'Constructing Traits'

2009-08-01T13:12:41-07:00

Constructing Traits

Traits don’t support auxiliary constructors, nor do they accept an argument list for the primary constructor, the body of a trait. Traits can extend classes or other traits. However, they can’t pass arguments to the parent class constructor (even literal values), so traits can only extend classes that have a no-argument primary or auxiliary constructor.

oops copied the wrong section into the buffer, meant to copy this


scala> class X (i:Int) {          

     |    require(i > 10)
        |    def this(a:Int, b:Int) = {
        |      this(a)               

     |    }                       

     | }                          

defined class X

scala> trait Y extends X{}        

defined trait Y

— maddalab (2009-08-01 13:12:41)

Comment on 'Constructing Traits'

2009-08-01T13:09:09-07:00

Constructing Traits

so traits can only extend classes that have a no-argument primary or auxiliary constructor
   scala> class X (i:Int)
   defined class X

scala> trait Y extends X{}
   defined trait Y
   
— maddalab (2009-08-01 13:09:09)

Comment on 'Introducing Traits'

2009-07-30T04:41:01-07:00

Introducing Traits

A class can extend a trait and a trait can extend a class. In fact, our Widget class above could have been declared to be a trait.

A class can extend a trait and a trait can extend a class. In fact, our Widget class above could have been declared to be a trait.

Which is correct, except the semantics vary a little, extending a trait with a class or trait (in additional to the traditional inheritance semantics) restricts the type into which the trait can be mixed in.
   abstract class Person
   defined class Person

trait Speaker extends Person {}
   defined trait Speaker

abstract class Animal
   defined class Animal

class PhilosophicalFrog extends Animal with Speaker{}
   :7: error: illegal inheritance; superclass Animal
    is not a subclass of the superclass Person
    of the mixin trait Speaker
          class PhilosophicalFrog extends Animal with Speaker{}
                                                      ^

class PhilosophicalMan extends Person with Speaker{}
   defined class PhilosophicalMan
   
— maddalab (2009-07-30 04:41:01)

Comment on 'Introducing Traits'

2009-07-30T04:28:17-07:00

Introducing Traits

into this statement,

ahh got it, I had declared observers as a val instead of a var, the operation+assignment sugar is only available on vars, which makes sense.
— maddalab (2009-07-30 04:28:17)

Comment on 'Introducing Traits'

2009-07-30T04:21:46-07:00

Introducing Traits

into this statement,

dope sorry. special by me, do not know what I was doing there, typed the wrong thing in the console
— maddalab (2009-07-30 04:21:46)

Comment on 'Introducing Traits'

2009-07-30T04:19:03-07:00

Introducing Traits

into this statement,

typo

observers ::= observer

should be

observer :: observers

there is no ::= method on a List and is there were

observer ::= observers

would be

observer.::=(observers)

where as

observer :: observers

is

observers.::(observer)
— maddalab (2009-07-30 04:19:03)

Comment on 'Constructing Traits'

2009-07-04T10:04:32-07:00

Constructing Traits

Notice the order of invocation of the class and trait constructors. Since the declaration of C12 is extends Base12 with T1 with T2, the order of construction for this simple class hierarchy is left to right, starting with the base class Base12, followed by the traits T1 and T2, and ending with the C12 constructor body. (For constructing arbitrarily-complex hierarchies, see the section called “Linearization of an Object’s Hierarchy” in Chapter 7, The Scala Object System.)

Hmm. Good question! I think there was a reason that vanished as I refactored this code! Will fix.
— deanwampler (2009-07-04 10:04:32)

Comment on 'Stackable Traits'

2009-07-04T10:02:39-07:00

Stackable Traits

In fact, super will be bound when this trait is mixed into an instance that defines a concrete click method, such as Button. Therefore, we need an abstract keyword on ObservableClicks.click to tell the compiler (and the reader) that click is not yet fully implemented, even though ObservableClicks.click has a body.

You could use a self type here. That's a topic that takes some explanation and discussion of design tradeoffs, which we come back to several times later in the book.
— deanwampler (2009-07-04 10:02:39)

Comment on 'Introducing Traits'

2009-07-04T09:55:37-07:00

Introducing Traits

Next, we declare a list of observers. We make it a var, rather than a val, because List is immutable, so we must create a new list when an observer is added using the addObserver method.

I made that choice to minimize distractions required to introduce new library types to the reader, but a note would be a good way to bring up the topic without too much disruption.
— deanwampler (2009-07-04 09:55:37)

Comment on 'Introducing Traits'

2009-07-04T09:53:23-07:00

Introducing Traits

Except for the trait keyword, Subject looks like a normal class. Subject defines all the members it declares. Traits can declare abstract members, concrete members, or both, just as classes can (see the section called “Overriding Members of Classes and Traits” in Chapter 6, Advanced Object-Oriented Programming In Scala for more details). Also like classes, traits can contain nested trait and class definitions and classes can contain nested trait definitions.

Actually, it's in Application Design, specifically "Self-Type Annotations and Abstract Type Members" where we revisit this particular issue of "Any" vs. "Subject" as the argument's type.
— deanwampler (2009-07-04 09:53:23)

Comment on 'Introducing Traits'

2009-07-04T09:47:49-07:00

Introducing Traits

Alexander, There's actually a good reason involving the way things type check. We'll get to it in the Type System chapter. I'll put some text here to provide a "hint" about why we used Any.
— deanwampler (2009-07-04 09:47:49)

Comment on 'Introducing Traits'

2009-07-04T09:45:37-07:00

Introducing Traits

There’s a lot going on here. The primary constructor takes a label argument and a list of callbacks that are invoked when the button’s click method is invoked. We’ll explore this class in greater detail in Chapter 5, Basic Object-Oriented Programming in Scala. For now we want to focus on one particular problem. Not only does ButtonWithCallbacks handle behaviors essential to buttons (like clicking), it also handles notification of click events by invoking the callback functions. This goes against the Single Responsibility Principle [Martin2003], a means to the design goal of separation of concerns. We would like to separate the button-specific logic from the callback logic, such that each logical component becomes simpler, more modular, and more reusable. The callback logic is a good example of a mixin.

Mario, thanks for the catch. Will fix. David, unfortunately, we can't put all this on one line, because it will be too long for the book format. There's obviously plenty of room on the web page. I'll think about alternatives.
— deanwampler (2009-07-04 09:45:37)

Comment on 'Introducing Traits'

2009-06-24T03:15:57-07:00

Introducing Traits

The with keyword is analogous to Java’s implements keyword for interfaces. You can specify as many traits as you want, each with its own with keyword.

Forget the first comment. Stackable traits / Linearization will be mentioned in a later section!
— magle (2009-06-24 03:15:57)

Comment on 'Introducing Traits'

2009-06-23T18:03:42-07:00

Introducing Traits

I am afraid I found the formatting of the ButtonWithCallbacks class confusing. Perhaps it is because I am a Scala novice, and I don't expect arguments to follow the class definition. The first time I read through the ButtonWithCallbacks code it didn't understand that label and clickedCallbacks were constructor arguments, I thought they were members.

I think that something like the following alternate formatting might be clearer.

class ButtonWithCallbacks(val label: String, val clickedCallbacks: List[() => Unit]) extends Widget {
— dhlbrk (2009-06-23 18:03:42)

Comment on 'Stackable Traits'

2009-06-23T04:51:12-07:00

Stackable Traits

I'm not sure, but would it be another option here to declare a self type for trait ObservableClicks ( 'self: Clickable =>' ) that forces the trait to be mixed in at least to an instance of type Clickable (so ObservableClicks could be sure, that it will be mixed in to a Clickable instance and therefore is able to call super.click() in a safe way)?
— magle (2009-06-23 04:51:12)

Comment on 'Introducing Traits'

2009-06-23T00:38:41-07:00

Introducing Traits

The with keyword is analogous to Java’s implements keyword for interfaces. You can specify as many traits as you want, each with its own with keyword.

It may be mentioned in a later section that traits are stackable. So if you mix in multiple traits which all implement the same method, a call to super.method() will invoke the method (with the same signature) on the next trait down the 'stack' (the order in which the mixed in traits are 'pushed onto the stack' is determined by a so called 'Linearization')
— magle (2009-06-23 00:38:41)

Comment on 'Introducing Traits'

2009-06-22T08:44:10-07:00

Introducing Traits

Next, we declare a list of observers. We make it a var, rather than a val, because List is immutable, so we must create a new list when an observer is added using the addObserver method.

I would also vote for a mutable List / ListBuffer in this case, since you don't construct the Observer's List at one time and use it unchanged afterwards but have a collection of observers that could change at any time.
— magle (2009-06-22 08:44:10)

Comment on 'Introducing Traits'

2009-06-22T08:24:08-07:00

Introducing Traits

Simple typo: 'when the button’s click method in invoked' is likely meant to be 'when the button’s click method is invoked'
— magle (2009-06-22 08:24:08)

Comment on 'Constructing Traits'

2009-06-13T17:28:53-07:00

Constructing Traits

What is the point of creating two C12 objects? Should we've been surprised that the creation of the two objects followed the same execution path? Or did you mean to create the second object from a class like "class C21 extends Base12 with T2 with T1". If so, it might be good to rename Base12 to Base (and to remove the "After creating.." print lines).
— battisti (2009-06-13 17:28:53)

Comment on 'Introducing Traits'

2009-06-13T16:14:23-07:00

Introducing Traits

Next, we declare a list of observers. We make it a var, rather than a val, because List is immutable, so we must create a new list when an observer is added using the addObserver method.

A short explanation of why you choose that approach (immutable datatype assigned to a 'var') instead of using a mutable datatype with an 'val' e.g. val observers = ArrayObserver would be interesting as a side note.
— battisti (2009-06-13 16:14:23)

Comment on 'Introducing Traits'

2009-06-13T16:10:13-07:00

Introducing Traits

Why is the type of subject in:" type Observer = { def receiveUpdate(subject: Any) } " Any and not Subject?
— battisti (2009-06-13 16:10:13)

Comment on 'Introducing Traits'

2009-06-08T18:45:54-07:00

Introducing Traits

Thanks. will fix.
— deanwampler (2009-06-08 18:45:54)

Comment on 'Introducing Traits'

2009-06-08T18:11:34-07:00

Introducing Traits

Have a look at the following code for a button in a graphical user interface, which uses callbacks for “clicks”.

We're following (or will follow..) a convention that file names ending in "-script.scala" are scripts while others are compiled files. Will add a description in the preface that explains this.
— deanwampler (2009-06-08 18:11:34)

Comment on 'Introducing Traits'

2009-06-02T09:27:21-07:00

Introducing Traits

concrete need the markup fixed (concrete_??)
— parthm (2009-06-02 09:27:21)

Comment on 'Introducing Traits'

2009-06-02T09:17:22-07:00

Introducing Traits

Have a look at the following code for a button in a graphical user interface, which uses callbacks for “clicks”.

It can be mentioned that the example below is not runnable.
— parthm (2009-06-02 09:17:22)