Problem Set 10

Due date: 12/01 @ 10:00pm

Purpose:

This problem set will be released in two stages.

The goal of the second stage is to explore the extensibility claims about object-oriented programs (while preserving the organization of the first stage). The exercises below demand the extension of existing solutions with both new variants (parts of a union) and new functionality. In the ideal world, you would not be allowed to modify the existing solution(*). If you had followed the guidelines and design strategies of HtDP and HtDC, such an "ideal" update would be within reach. Unfortunately most of you didn't follow the rules and guidelines, meaning you will have to rewrite your entire program.

The goal of this first stage is to introduce abstract classes, to add proper privacy specifications, and to deploy stateful programming properly (if needed).

Drill:

HtDC: 18.7--18.13, 19.8/9, 19.12-19.15, 20.7--12, 21.1--3, 21.4, 23.9--13, 24.4, 24.10--14, 26.4/5, 27.6.1--4, 27.8 (all), 28.1, 28.2, 28.3, 28.4--6

Required Problems:

Note: You must use the ProfessorJ Intermediate+access language level for all problems. You must also use the idraw library instead of the boolean based one.

Submission: Your submission directory for this problem set should consist of two files, labeled 1.ss and 2.ss. These primary files should contain reasonably large examples for testing your code with non-trivial inputs. If you do write scripts to create stress tests, add a directory called Aux and place the scripts there.

Stage 2:

released: Sat, Nov 22, 8:22pm

Design the following two extensions for your representation of enumerations from problem 9.1:
- a renderHTML method, which produces a string that a web browser could interpret as a HTML enumeration. Here is what you need to know about a HTML:
  
  <ol> opens an ordered enumeration
  
  <ul> opens an unordered enumeration
  
  <li> opens an item in an enumeration
  
  These opening tags must be closed with </li>, </ul>, and </ol>, respectively. Here is a simple example:
```
<ol>
  <li> item 1 </li>
  <li> 
    <ul>
      <li> nested unordered item 1 </li>
      <li> nested unordered item 2 </li>
    </ul>
  </li>
  <li> item 3 </li>
</ol>
```
  Copy and paste this block into a file with an ".html" extension and open it in your browser.
Design the following two extensions to your representation of boolean expressions from problem 9.3:
- the representation of a show expression:
```
   A boolean expression (BE) is one of: 
   -- boolean 
   -- variable symbol
   -- ! BE
   -- BE && BE
   ++ show(BE)
```
  The purpose of a show expression is to determine the value of its subexpression, to return this value and to simultaneously display it on a canvas.
  To represent show expressions, we introduce a new class that is initialized with a BER (the representation of the subexpression) and a Canvas (c) and a Posn (p). When your evaluator method evaluates an instance of Show, it displays the value of the subexpression on c at the given position p. If you have more than one Show subexpression, make sure their Posns are sufficiently far enough apart so that you can see all results, e.g.,
  Of course, if (the representation of) a boolean expression contains variable symbols, no output should appear on the canvas.
- a substitute method, which replaces all variable symbols with a given boolean value. That is, its signature is
```
// replace all variable symbols in this IBER with 
// a (representation of) the boolean d
IBER substitute(boolean d)
```

Stage 1:

released: Fri, Nov 21, 6:44pm

Abstract common methods (and fields) from your solution for problem 9.1. Introduce privacy specifications for each field and method in every class.
Design the method render for your (one and only) Examples class for problem 9.1. It should have the following signature and purpose:
```
 // render e on a canvas that is 800 pixels wide and 
 // as tall as necessary to render the entire enumeration 
 boolean render(IEnum e)
```
In order to stress test your solution of problem 9.1, you may wish to design a script that creates arbitrarily nested unordered enumerations or you may wish to use mine. Please ponder why this render method isn't really a method in the sense of Java or other object-oriented methods. There is a concise answer and indeed, one word suffices.
Abstract common methods (and fields) from your solution for problem 9.3. Introduce privacy specifications for each field and method in every class.
Design your own stress test for problem 9.3. The stress test should involve an arbitrarily deeply nested and expressions (without variables). Make sure that the evaluation of and expressions short-circuits, i.e., does not evaluate the second expression if the first one is false. Test your solution for problem 9.3 gradually, with deeper and deeper expressions. My solution consumes time linear in the number of nodes.

(*) For example, you might not have access to the source code; instead you might be forced to program to an "interface" and link to object code. Alternatively, you might be forced to update a running program without disturbing the execution too much.