The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

Which scala version does the book use?
The author mentioned a result type that is available in the community but I don't know exactly which one it is. I tried searching and I found but it seems slightly different from the one presented in the book.

I'm interested in having the
The git hub for chapter 10 is not available to me. I get a 404 on
Suppose we have the following situation. We have an api that returns a book `Title`. Chapter 5 suggests that we do not leak our domain primitives in the api so the title is returned as a JSON string to clients. Initially there was server side validation and client side validation to make sure a title does not have a blank value.

Suppose that the clients are mobile clients apps. This makes it difficult to update the client api if the server api changes. Now suppose you evolve the api to produce blank titles. This is not part of the api so it is valid since it is a string but it breaks old clients validating the title.

How can I maintain a stable client and validate data from data transfer objects?
Conditional conformance is a good idea but not sure how it plays out in practice beyond Equatable and Hashable. Do you have any insight?

What happens in the following example?

protocol Foo {
    func getBar() -> Int

struct FooOne: Foo {
     func getBar() -> Int { return 1 }

struct FooTwo: Foo {
    func getBar() -> Int { return 2 }

struct FooPair<T: Foo, U: Foo> {
    let f1: T
    let f2: U

let fooOne = FooOne()
let fooTwo = FooTwo()

let fooPairOne = FooPair(f1, f2)
let fooPairTwo = FooPair(f2, f1)
let fooPairThree = FooPair(f1, f1)

print(fooPairOne.getBar())  //what happens here?
print(fooPairTwo.getBar())  //what happens here?
print(fooPairThree.getBar())  //what happens here?
The first point that isn't clear from the text is that if two objects/structs are equal they should have the same hash value. The example with custom hash functions does not cover this. It important since hashing is built on the assumption that equality implies same hash code. If you violate this then you will not necessarily get correct results from dictionaries and sets.

In general if two things are equal they should behave the same.

Second point is that in general the quality of the hash function depends on the distribution of the sample set. Maybe not something to go into detail but something to call out. When the author says XOR is not a good hash function it has an implicit assumption about the distribution of the Pairs to be used.
I think it would be nice to have all the exercises in the beginning of the chapter. I would like to think about them as I read.
The link for the properties playground is not available. I assume it was at one point in time.
For the class

data class Price private constructor(private val value: Double) {
    override fun toString() = value.toString()
    operator fun plus(price: Price) = Price(this.value + price.value)
    operator fun times(num: Int) = Price(this.value * num)

    companion object {
        val identity = Price(0.0)
        operator fun invoke(value: Double) = if (value > 0)
            throw IllegalArgumentException("hello")

It is supposed to guarantee that the price is always positive but using the copy method you can break this.

The following test

fun test_negative_price_allowed_using_copy_method() {
    val validPrice = Price(12.0)
    // should be invalid but is not
    val invalidPrice = validPrice.copy(value = -1.0) 
    val identity = invalidPrice + Price(1.0)
    // shows that invalid price.value == -1.0
    assertEquals(identity, Price.identity)
Q: What are the number possible variations of Bagel?

enum Topping {
    case creamCheese
    case peanutButter
    case jam 

enum BagelType {
    case cinnamonRaisin
    case glutenFree
    case oatMeal
    case blueberry

struct Bagel {
    let topping: Topping
    let type: BagelType

The answer is 12 since structs are product types and 3 * 4 = 12.

I don't know how to use the xcode stack trace to find the line so I attached my console output.

Steps to reproduce.

1) Checkout Chapter11.7.StoreCoreData branch from book repo
2) Add a book
3) Switch to collection view
4) Click on a book
I get a crash when I select a book in the BookCollectionViewController
I did mistype the suggestion.

it was supposed to be = self.fetchedResultsController.sections?[selectedIndexPath.section - 1].objects?[selectedIndexPath.row] as? Book

updated original comment
Line 62 of BooksCollectionViewController.swift is = self.fetchedResultsController.object(at: selectedIndexPath)

suggested fix is

(edit) = self.fetchedResultsController.sections?[selectedIndexPath.section - 1].objects?[selectedIndexPath.row] as? Book
now it is Rx Java 2.
Thanks for the gifs. Now I see what I was missing.
I tested it before the changes and I had the same behavior. That is why I'm still confused.
In 11.1.1 I'm not sure what state we are saving. I ran the app with preserving the application state and without preserving the application state, on the book's branch and mine. In all cases the tab preference is saved when you background the app and foreground it again. But in neither case is it saved after killing the process. What am I supposed to see or do?
Found the following error, 10.2.1 Instruction 3. It does not match the repo. Also the navigation bar disappears when you click on an item during a search.

Turn this off, too:
searchController.definesPresentationContext = true

Should be

Turn this on:
definesPresentationContext = true
Will there be much differences between the content in The Joy of Kotlin and Functional Programming in Java?
It doesn't matter that much. The main thing kotlin brings to Rx is lambdas and method references. Otherwise not a big deal.
The architectures and principles presented in the book are still valuable.
Alexander Gherschon wrote:Even if the concepts are the same, why not align the book with the latest stable version?

It is a book and RxJava 2 is relatively new. I assume he started writing before they updated.

Alexander Gherschon wrote:It feels like we should still consider RxJava 1 in new projects by not addressing that point...

RxJava 1 will be deprecated in March 31, 2018
Section 1.6 requires Carthage to be installed on the machine. Package managers are not mentioned in Chapter 1
Another difference is that in RxJava 1 it seems like you could add an unsubscribe callback to a subscription. In RxJava 2 see the source code for the RxJava binding to get an idea how this can be done
Ch 4 Difference, subscriptions

RxJava 1.x has

RxJava 2.x has
So far, Ch 1- 3 do not distinguish between RxJava 1 or 2
For RxBinding use
Don't use the Jack compiler, it is deprecated. Android Studio 3.0 supports Java 8 Lambdas (not Streams)
I would say the differences between RxJava 1 & 2 are subtle and probably will not come up in the book. I'll try to update if I notice anything substantial.
I believe this has been fixed in v8
Do you have a specific use case in mind?
I don't think it should have a substantial effect.
I agree. Would like at least readable images.