- update fingerprint to:
  "81" + sha256("2016summerIII-ibarland") + "4"
  echo -n "2016summerIII-ibarland" | gpg --print-md sha256 | cut -c1-5 | echo 81 - 4

  2016summerIII: 0x815F58D4  ...except that my solution also included some 0x81A605A4
  2015fall: 0x814F8614
- change "format" to "number->string"
- make into student-intermediate-level
- in R0, swap the order of the 'add a binop' and 'add a ifZexpr'
  Make sure we have the funcs so we can write factorial and maybe 3n+1, later!
- (ask for some sample R expressions earlier?)
- change/combine "string->expr" to be "parse"? (w/ a comment)

Substitutions:
  matey -> mates; 
  '@' to '#' (except @author, @version, @see, @param, etc)




blueroom:

@William:

<p>
<i>
&gt; to distinguish “has-a” from “uses” arrows, would all be nice features for a future version<br/>
&gt;<br/>
</i>
Yes, this is all I'm saying.
</p>

<p>
Part of my course is teaching the Composite pattern,
which means focusing on how BinExpr is-a Expr, but BinExpr also has-a Expr.
So I want the students to be able to focus on that (with the appropriate amount of fear :-)
</p>

<p>
But just becase an Expr(ession) has one method (eval(uate)) which returns a Num(ber),
having ten arrows pointing to class Num aren't really that helpful.
(Certainly not the five emanating from the test-classes!)
So even though each class has a method that will return a Num,
and so it's true that each of those classes will need to call `new Num( .. )` correctly,
the arrows as shown overstate the case, and obscure the real architecture of the program.
<br/>
[Consider somebody implementing an accounting system, and they have a class 'Amount'.  That
class is likely used by many many others -- so there is coupling, but showing
every arrow for it arguably obscures the important relations.]
</p>


<p>
You're right, putting 'UtilIan' and 'Pair' in a nested package -- or really, an entirely separate
package -- would be the proper (industrial) way.  But of course I'm making compromises to keep things
simpler for students, too.
</p>

<p>
Maybe part of the "problem" is BlueJ's success -- it's such a fantastic tool, esp. for beginning students,
that I start thinking about all sorts of other features which balance simplicity with expressiveness.
I don't mean to take BlueJ for granted, and only sound nagging in feature-requests.
I can't imagine using a different IDE in the classroom, and every time I use it I want
to give a big thanks to the BlueJ team.  So:
<br/>**Thanks**!
</p>










> I like a clean diagram, too, but the fear Ian’s students have is not unwarranted. According to the second diagram, for example, a bug in the Num class will break every other piece of code in the project, so that students with BlueJ experience will know to be cautious with this class. The cycle in the diagram where:

Num -isa-> Value -isa-> Expression -uses-> Num
shows a reason for even more caution: I warn students routinely that such cycles make debugging difficult. The Utillan and Value classes in Ian’s example are similarly important. If a student working on BinExpr calls a method in the Value class incorrectly, s/he needs to know where to resolve the problem, and the arrow indicating that “BinExpr -uses-> Value” is a useful clue.

I don’t mean to criticize Ian. I have created examples that are even more complex, seen the same fear in students’ eyes, and I admire his post for putting the issue so plainly. I’m also guilty of cheating, by hiding a much-used class like Utillan in a subfolder, so that BlueJ will treat it as a package and get rid of the arrows.

It is nice to simplify diagrams for the Day 1 presentation. Options to hide arrows, singly or by type, and to distinguish “has-a” from “uses” arrows, would all be nice features for a future version of BlueJ.

The current behavior, which leaves an arrow in place after a dependency is removed, is a priority
bug to fix. More broadly, I hope the next version will display every dependency between classes by
default, and update those dependencies every time the code changes. The correspondence between the
diagram and the code helps students find bugs that cross class boundaries. It also implicitly
encourages us to write cleaner code.