CS/SWE 332 In Class Exercise Number 16
October 23, 2017

Name(s):

The first exercise (which revisits the same problem as exercise #3) is intended to get you to think about Liskov's argument about equals(). The following is "normal" Java:

Set<List<String>> s = new HashSet<List<String>>();     // AF(s) = ___
List<String> x = new ArrayList<String>();  // AF(x) = ___
List<String> y = new ArrayList<String>();  // AF(y) = ___

s.add(x);		 // AF(s) = ____
s.add(y);		 // AF(s) = ____

s.contains(y)            // true or false?

y.add("cat");	         // AF(y) = ____
                         // AF(s) = ____

s.contains(y);           // true or false?

s.add(y);		 // AF(s) = ______

y.remove("cat");	 // AF(y) = ______
                         // AF(s) = ____

s.remove(y);		 // AF(s) = ______

s.contains(y);		 // ???
s.contains(x);		 // ???
What does this sequence have to do with with the equals() method?

How do you know?

Fill in the values.

In the language of contracts, what does this code do?

What is Liskov's argument for equals() wrt mutability, and what is her rationale?


Now, let's turn to related subtypes.
  1. Define an implementation of Comparator that reverses the natural ordering.

    Does this implementation satisfy the Comparator contract?

    Can you generify this implementation?

  2. Repeat the exercise with a Comparator<Integer> that uses absolute values.

  3. Repeat the exercise with a Comparator<Integer> that orders evens before odds.