Comments on Programming Scala

Comment on 'Overriding Members of Classes and Traits'

2009-08-02T16:42:08-07:00

Overriding Members of Classes and Traits

While it appears that we are creating an instance of the trait with new AbstractT2 …, we are actually using an anonymous inner class that implicitly extends the trait. This script shows what happens when inverse is calculated

why is the new type definition of AbstractT2 an "anonymous inner class" and not just an "anonymous class"?
— maddalab (2009-08-02 16:42:08)

Comment on 'Case Classes'

2009-07-12T21:47:01-07:00

Case Classes

The second circle is created by copying the first and specifying a new radius. The copy method implementation that is generated by the compiler exploits the new named and default parameters in Scala version 2.8, which we discussed in the section called “Method Default and Named Arguments (Scala Version 2.8)” in Chapter 2, Type Less, Do More. The generated implementation of Circle.copy looks roughly like the following.

Doh! Thanks.
— deanwampler (2009-07-12 21:47:01)

Comment on 'Companion Objects'

2009-07-12T21:46:30-07:00

Companion Objects

This code compiles fine, but if you attempt to invoke Person.main, using scala -cp ... objects.Person, you get the following error.

Yea, I think the typical "production" main would end up in its own object. The gotcha is most likely to happen when you put a "test" main in a class for convenience, but it doesn't work!
— deanwampler (2009-07-12 21:46:30)

Comment on 'Companion Objects'

2009-07-12T21:45:08-07:00

Companion Objects

Button.unapply takes a single Button argument and returns a Some wrapping the label value. This demonstrates the protocol for unapply methods. They return a Some wrapping the extracted fields. (We’ll see how to handle more than one field in a moment.)

Good point. Thanks. Need to decide on a good place for this.
— deanwampler (2009-07-12 21:45:08)

Comment on 'Overriding Members of Classes and Traits'

2009-07-12T21:43:16-07:00

Overriding Members of Classes and Traits

Most OO languages allow you to override mutable fields (var). Fewer object-oriented languages allow you to define abstract fields or override concrete immutable fields (val). For example, it’s common for a base class constructor to initialize a mutable field and for a derived class constructor to change its value.

Thanks. will fix.
— deanwampler (2009-07-12 21:43:16)

Comment on 'Case Classes'

2009-07-08T15:16:44-07:00

Case Classes

The code should be "circle1 copy (radius = 4.0)".
— jesnor (2009-07-08 15:16:44)

Comment on 'Companion Objects'

2009-07-03T22:56:04-07:00

Companion Objects

Perhaps it would be interesting to point out that unapply can also return a Boolean, in which case it just matches, but does not extract anything?

object isInt { def unapply(s: String): Boolean = s matches "\d+" }

"54" match { case isInt() => println("Yep.") case _ => println("Oops!") }
— dcsobral (2009-07-03 22:56:04)

Comment on 'Companion Objects'

2009-06-24T22:11:17-07:00

Companion Objects

This code compiles fine, but if you attempt to invoke Person.main, using scala -cp ... objects.Person, you get the following error.

We like putting our main methods in a Main object. Seems redundant but there's never confusion about which method to call.
— stevej (2009-06-24 22:11:17)

Comment on 'Overriding Members of Classes and Traits'

2009-06-21T10:53:35-07:00

Overriding Members of Classes and Traits

allow you to override
— robcd (2009-06-21 10:53:35)