This activity came out of producing a Scratch Player in Flash, and I wanted to see whether the parse of the file produced the correct program. A textual dump of the parse was an obvious solution, but then this ‘dump’ might as well be the same as a complete program declaration so it was clearly ‘complete’ and I wasn’t missing anything.

Scratch Textual

The core concepts in this proposed textual language for Scratch are:

• It should match Scratch as closely as possible
• It should be a readable and easily writeable textual language (vs. XML as an interchange format)
• It should be translatable to other human languages for the blocks (as Scratch is)
• It should be really simple to produce and parse
• Given Scratch is graphical, visual indentation is reasonable
• It is not a complete ‘dump’ of the Scratch project — no media resources are included.

The above concepts produced the following initial choices:

• Different sections start with simple keywords: “stage:” and “sprite:” for the main objects, “vars:” and ‘listVars:” for declaring variables, “comment:” for a comment section, and “script:” for declaring a sequence of blocks.
• Variables simply define their name and an initial value (if desired… otherwise it would be ’0′)
• Each block is written out textually with its ‘spec’ — a human readable description of the block and its parameters
• The parameters to a block (if any) come immediately after, and are preferably indented [say 4 spaces] from the block they are parameters too. Note that the indentation is not necessary because you can tell the number of parameters from the block ‘spec’, but indenting makes it more readable.
• If a block can contain other blocks, contained blocks _must be_ indented [say 4 spaces] so you can tell they are inside the block vs. after the block. This is in a fashion similar to Python.
• There should be no blank line within a ‘script:’ section. The end of a script: section is the first blank (non-comment) line.
• Comments within the textual blocks use ‘#’ to match with Python. Multi-line comments do not exist. Note that Textual Comments are not parsed at all (and do not round-trip), so they should be minimal and merely augment parsing the textual source — use ‘comment:’ for real documentation.
• ‘script:’ and ‘comment:’ could have position information after them using the ‘loc’ property (e.g. “loc = 500@250″) but this is not likely to be useful since any edits would cause positions to be wrong

An Example

The following is a complete “normal expanded format” version. See further below for a possible optimization to make things more vertically compressed.

#===========================
#=== Morph: Stage 
#===========================
stage: Stage

#============
#=== Vars 
#============

vars:
talest-pole-height = 6
previous-moved-disk = 0
potential-disk = 1
num-disks = 5
next-disk = 0
base-disk = 0

listVars:
pole-1 = undefined
pole-2 = undefined
moveable-disks = undefined
pole-3 = undefined

#============
#=== Script 
#============
script:

when 'find-next-disk'
set next-disk to %n
    0
broadcast %e and wait
    propose-next-disk
repeat until %b  
    %n > %n
        next-disk  
        0
    set potential-disk to %n
    if %b  
        not %b
            %n = %n
                potential-disk  
                previous-moved-disk  
        set next-disk to %n
            potential-disk  
broadcast %e and wait
    move-next-disk

#============
#=== Script 
#============
script:

when 'Scratch-StartClicked'
set num-disks to %n
    5
set base-disk to %n
    %n + %n
        num-disks  
        1
set next-disk to %n
    num-disks  
repeat until %b  
    %n < %n
        next-disk  
        1
    set next-disk to %n
        %n - %n
            next-disk  
            1
broadcast %e and wait
    initialize
set previous-moved-disk to %n
    0
set talest-pole-height to %n
    0
repeat until %b  
    %n > %n
        talest-pole-height  
        num-disks  
    broadcast %e and wait
        find-next-disk
    set talest-pole-height to %n
    if %b  
        %n > %n
            talest-pole-height  
        set talest-pole-height to %n


#===========================
#=== Morph: Sprite1 
#===========================
sprite: Sprite1

#============
#=== Vars 
#============

vars:
can-move = 3
am-on-top = 1
disk-id = 1
pole = 3
height = 6
previous-pole = 1
pole-at-start = 1

#============
#=== Script 
#============
script:

when 'move-next-disk'
if %b  
    %n = %n
        disk-id  
        next-disk  
    set previous-moved-disk to %n
        disk-id  
    set pole-at-start to %n
        pole  
    if %b  
        %b and %b
            not %b
                %b or %b
                    %n = %n
                        previous-pole  
                        1
                    %n = %n
                        pole  
                        1
            %n < %n
                disk-id  
        set pole to %n
            1
    if %b  
        %b and %b
            not %b
                %b or %b
                    %n = %n
                        previous-pole  
                        2
                    %n = %n
                        pole  
                        2
            %n < %n
                disk-id  
        set pole to %n
            2
    if %b  
        %b and %b
            not %b
                %b or %b
                    %n = %n
                        previous-pole  
                        3
                    %n = %n
                        pole  
                        3
            %n < %n
                disk-id  
        set pole to %n
            3
    set previous-pole to %n
        pole-at-start  
    if %b  
        %n = %n
            previous-pole  
            1
    if %b  
        %n = %n
            previous-pole  
            2
    if %b  
        %n = %n
            previous-pole  
            3
    if %b  
        %n = %n
            pole  
            1
        set height to %n
    if %b  
        %n = %n
            pole  
            2
        set height to %n
    if %b  
        %n = %n
            pole  
            3
        set height to %n

#============
#=== Script 
#============
script:

when 'propose-next-disk'
set am-on-top to %n
    0
set can-move to %n
    0
if %b  
    %b and %b
        %n = %n
            pole  
            1
        %n = %n
            disk-id  
    set am-on-top to %n
        1
if %b  
    %b and %b
        %n = %n
            pole  
            2
        %n = %n
            disk-id  
    set am-on-top to %n
        1
if %b  
    %b and %b
        %n = %n
            pole  
            3
        %n = %n
            disk-id  
    set am-on-top to %n
        1
if %b  
    %n > %n
        am-on-top  
        0
    if %b  
        %b and %b
            not %b
                %b or %b
                    %n = %n
                        previous-pole  
                        1
                    %n = %n
                        pole  
                        1
            %n < %n
                disk-id  
        set can-move to %n
            1
    if %b  
        %b and %b
            not %b
                %b or %b
                    %n = %n
                        previous-pole  
                        2
                    %n = %n
                        pole  
                        2
            %n < %n
                disk-id  
        set can-move to %n
            2
    if %b  
        %b and %b
            not %b
                %b or %b
                    %n = %n
                        previous-pole  
                        3
                    %n = %n
                        pole  
                        3
            %n < %n
                disk-id  
        set can-move to %n
            3
    if %b  
        %n > %n
            can-move  
            0

#============
#=== Script 
#============
script:

when 'initialize'
set disk-id to %n
    1
set pole to %n
    1
set previous-pole to %n
    0
set can-move to %n
    0
set am-on-top to %n
    0
set height to %n
    %n + %n
        %n - %n
            base-disk  
            disk-id  
        1

Vertical Compression

The format above has every block on its own line. This is readable and informative (you can see the argument types) but is vertically expansive. Assuming parentheses or some other paired delimiter are not used for anything else in names, we could replace the argument placeholders with parentheses like below. This gives a more lisp-like feel, at least for the inner evaluations. If you leave one or more placeholders off, they would come from the next lines in ‘missing’ order, kind of like a macro.

script:

when 'find-next-disk'
set next-disk to (0)
broadcast (propose-next-disk) and wait
repeat until ((next-disk) > (0))
    set potential-disk to (0)
    if (not ( (potential-disk) = (previous-moved-disk)) )
        set next-disk to (potential-disk)
broadcast (move-next-disk) and wait

You can find the original book here:

• A Taste of Smalltalk
• Free Smalltalk Books

Given the original book is available online, I will not repeat it.

You can both see the example in Scratch and get tools and background on the Scratch project at:
Tower of Hanoi. The scratch tools and the community web site are free.

Tower of Hanoi — Object-Oriented (V4) — Scratch

The standard pattern for this series is to translate as closely as possible each of the chapters in “A Taste of Smalltalk” to the new target language. This worked reasonably well for Ruby and Flex — the Smalltalk was translated and interesting features of the language came out with each translation. But this approach utterly fails for Scratch because the first two ‘models’ of the Hanoi algorithm are completely dependent on recursion, which Scratch does not have. Even the third, stack-less version of Hanoi requires inter-object calls that Scratch can not handle. So _none_ of the algorithms within “A Taste of Smalltalk” can be directly translated to Scratch.

This might appear to be a limitation of the language (and in some ways it certainly is), but somewhat impressively, I believe thinking about this problem, with the restrictions of Scratch, actually leads to a better design solution than any of the ones in the book. It is certainly a very object-oriented solution, where the ‘Hanoi Disks’ have a lot of intelligence and are made as responsible as possible for figuring out what to do next. This version of the algorithm, I will call ‘V4′.

The V4 Algorithm

The V4 Algorithm works as follows:

1. Ask each of the disks whether they have a legal move
2. Decide which of the disks with a legal move should move
3. Tell that disk to move

The interesting parts of this algorithm are that:

• Step 1 can be completely parallel. You can ask 1 to 1000000 disks at the same moment whether they have a legal move.
• Step 2 is really trivial: just don’t move the same disk you did last time

Compared to the V3 version, the V4 version puts more intelligence in the disks (and less in the tower), couples them less, and supports mass parallel-execution. The parallel-execution is not useful in Hanoi, but the concepts behind it are definitely very interesting — and Scratch’s restrictions forces this kind of ‘sophisticated’ approach [or at least it forced me down this path to maintain code-sanity and maintainability].

The main Scratch Player view

Scratch is designed to be an easy-to-learn language and environment. Its heritage is along the lines of the spirit of Logo: there is a Stage drawing area and a default Sprite (a Cat) that you interact with for animation and drawing. But this Stage can also show the variables involved with the program. So it produces a nice overview of the whole Hanoi program:

Not all application variables are shown, but those shown are the most important ones. The details of the variables will be gone over later, but some are self-evident:

• num-disks: The number of disks (the height) of the Tower of Hanoi
• pole-#: A List (treated as a Stack) of Disk identifiers, where ’6′ = a base (immovable) disk
• movable-disks: A List of disks that can be moved. This is transitory for each iteration of the algorithm.

If you click the ‘Green Flag’, the program executes and on pretty much every step the display is updated, so you can see disks being proposed and moved (in both animation and variables). Independently of Scratch having a graphical programming language, it has a very nice graphical development and run environment.

Application Variables

The application variables are shown below. All of these are ‘Globals’ and can be accessed by any object. Those variables colored in red are lists and those colored in orange are numbers/strings/etc. All the variables that have check-marks next to them are being displayed on top of the Stage above.

There is no such thing as a ‘local’ variable (private to a block of code), so it might be useful to use a naming prefix to differentiate between ‘local’ variables (like ‘potential-disk’) from instance variables and even ‘parameter’ variables that go with a broadcast (‘next-disk’). But in-the-small, that is not particularly important.

Application Initialization

Now that we have an overview of the application and its global state variables, we can start working through the algorithm itself. The main ‘Object’ in Scratch is the Stage, and I made this own the outer-most aspects of the Hanoi application and algorithm. The first activity is ‘Initialization’, which is triggered by the ‘Green Flag’ [my particular choice].

Because this is the first example of Scratch, I will walk through the sections of the code and what they do with a few visual marker numbers (see the right column of blue).

When the Stage gets the Green Flag event:

1. It sets the number of disks to ’5′. This is hard-coded because Scratch is currently unable to clone Sprites (objects) on the fly, so we have to precreate all the needed sprites. In any case, this is simple enough to change if someone wants. The additional variable ‘base-disk’ is defined so it can be used below. ‘base-disk’ is just a local variable and is never used again. After this, we just clear the lists so they are ‘clean’
2. Next we add the ‘base-disk’ to the bottom of each pole. The base-disks are invisible and immovable (no matching Sprite/Object), so this is a very clean way of making the algorithm simpler later on.
3. Next we add the disks to ‘pole-1′ using what should be another local variable. Later I reuse this variable [something I don't like doing] just because we otherwise have a clutter of variables.
4. Next we send out a broadcast to _all objects_ telling them to initialize themselves. There is no direct message send to an object, so it is up to the other objects to know what to respond to and what to ignore. The broadcast waits until all object’s acknowledge they are finished.
5. Finally, we go into the main loop. Until all the disks have moved to a new pole, we will execute ‘find-next-disk’ which both finds and moves the next disk. When we are done, we make a noise

Find and Move Next Disk

The main part of the algorithm has some nice aspects and some nastier aspects. The nice side: We simply send out a broadcast of ‘propose-next-disk’, which all Disks should respond to by adding themselves to ‘movable-disks’ if they have a desire to move. This will only ever be one or two movable disks at any given time. One of those disks may have been moved immediately previously, so we skip over it. The selected disk is put into ‘next-disk’ and another broadcast goes out “move-next-disk”. The second broadcast is not really a broadcast. It is a message send to ‘next-disk’, but it is only by the disks themselves ignoring a broadcast that isn’t to them that it becomes a message send. So that is slightly nasty.

In any case, the code is pretty clean and concise, and this ends the code on the Stage itself. The rest of the algorithm is on the Disks.

Disks Variables

The Disks have access to all the Stage global variables. In addition, each Sprite can have its own instance-private variables, which are either true instance variables (‘disk-id’, ‘pole’, ‘previous-pole’) or would be local variables if Scratch supported them (‘can-move’, ‘am-on-top’, etc.)

Instance variables can be displayed on the Stage also, but this becomes overwhelming if all instances are turned on.

Disk Initialization

Upon receiving the ‘initialize’ broadcast, all Disks set their ‘disk-id’ (which must be different for each disk), and then set themselves up properly in size, color, and move onto the correct pole.

Propose Next Disk

Scratch has certain deficiencies that rear their heads badly in the Hanoi code. The concept of Propose Next Disk is as simple as:

If
   * I am on-top of a pole
   * And I can move to a new pole (with a bigger disk on its top)
   * And that new pole isn't the pole I just came from
Then
   * Add myself to the movable-disks list

But because Scratch (or my knowledge of Scratch) is deficient in dynamic referencing of variables, the ‘propose-next-disk’ code needs to expand all the potential pole values from 1 through 3. Fortunately this is only a three-valued expansion, but the code looks quite nasty for being as simple as the above.

Move Next Disk

The Move Next Disk code has (1) the filter on the broadcast (in this case by ‘disk-id’) to make it only go to a single object and (2) a ton of noise due to ‘pole’ expansion mentioned above. But the code gets the job done and it looks fairly colorful

Conclusions

I was impressed that Scratch was able to get Tower of Hanoi to run properly. Scratch has actively avoided certain features that the Scratch team finds are difficult to understand. But the toolbox of event processing, broadcasts, lists, and Sprites (objects with Stage presence ) are rich enough that a pre-sized Hanoi can be created and will run correctly. A dynamic Hanoi would require Sprite cloning, which is not in Scratch 1.3.

The nastiest aspect to Scratch was its inability to dynamically reference the pole lists. And a missing feature to Scratch are simple procedures (for example, the ‘glide’ code is repeated twice). The missing recursion is clearly another missing feature, but in this case getting rid of that recursion made the algorithm somewhat nicer.

On the whole, Scratch is a very inspiring visual language and development environment, and it did a good job with this ‘offbeat’ test.

1. Mark-Fussell (or mark-fussell)
2. MarkFussell
3. Mark_Fussell (or mark_fussell)

where the underscore goes third mostly because it can be hard to see [URLs and other things put underlines _on top_ of that underline like thus Mark_Fussell], is harder to type, and it over spaces things visually. So I (and lots of people actually) believe programming languages _should_ use hyphens, but because a bunch of programming languages want ‘a-b’ to be interpreted as ‘a – b’, they cop out and prevent the hyphen from being part of a name. Ruby has that same cop out, so we can’t use hyphens in Ruby

Missing Phrase Delimiter

So I said my opinion is fairly irrelevant, but I also want to say that people have missed an important aspect to this argument. I may have a small preference for CamelCase over underlines as a single word delimiter, but I have a _huge_ preference to having both a ‘word’ and a ‘phrase’ delimiter. And by insisting on just one delimiter in this naming standard, Ruby has significantly interfered with expressiveness. Maybe I am unusual, but I have long-time argued that we should have both words and phrases in methods and frequently even in classes. Back in the 1990s, I documented this as part of my JavaStandards and this was based on Smalltalk naturally having both of these pieces. It was clearly more readable and you were much less likely to produce bad method names.

For method naming, the quick summary is:

• When naming a method
• Start with a verb phrase (what you are asking the object to do)
• Put an underscore where a parameter is expected (up to the first two at least)
• Describe what that parameter is for right before the underscore, if it is not obvious from the verb

this way, the reader of the code can immediately know how the parameters (in the parentheses) map onto their role in the method itself. And the whole method name becomes a readable phrase… not just a weird long word strung together (by whatever convention you want).

Array::insert

So an example is:

Array::insert(index, obj)

This is a method name that is ambiguous in usage:

anArray.insert(3,2)

It is not clear what the code is going to do and I would actually intuitively expect it to be the other way around (except I know about getting burned so would then have to look it up).

A better name would be:

Array::insert_at(obj,index)

so reading:

anArray.insert_at(3,2)

is clearly inserting the ’3′ not inserting the ’2′.

Or if people like the order the other way:

   Array::insertAt_value(index,obj)

   anArray.insertAt_value(2,3)

And in the Ruby case where any number of values could follow, we should have:

   Array::insertAt_values(index,obj...)

   anArray.insertAt_values(2,3)
   anArray.insertAt_values(2,5,3)

and everything reads naturally something like this “anArray insertAt: 2 values: 5 and 3″.

forPolesOtherThan_do(disk)

Related to a recent post on the Tower of Hanoi, I believe the resulting choice of:

forPolesOtherThan_do(disk) [block]

is much clearer in both communicating what the passed in ‘disk’ is for and that it requires a block as a second (semi-hidden) argument than if you have only a word delimiter and have any of:

   for_poles_other_than
   for_poles_other_than_do
   forPolesOtherThan
   forPolesOtherThanDo

What to do?

Given Ruby wants to use underscore to separate words… I can’t separate the phrases at all. I tried to wrestle my mind around using something different, but Ruby surprisingly (for a modern and internationally-created) language does not have any other punctuation that is allowed and could plausibly work. So maybe use two underscores for the phrase point? That seems seriously ugly and also two underscores don’t really look different from one underscore:

   insert_at__values
   for_poles_other_than__do

Using capitals for this purpose just comes off weird (plausible but weird):

   insert_at_Values
   for_poles_other_than_Do

It is also exactly the opposite of Smalltalk, and I try to be able to work across languages without having to flip upside down all the time. Same regarding Java and Flex (two other languages I actively work in). For reference, the Smalltalk version of these examples are:

   insertAt: values:
   forPolesOtherThan: do:

Arguments about non-English speakers

One argument I (so far) find specious is that using capitals prevents non-native speakers from understanding the code. I could maybe believe this is true in rare cases — but (1) nobody has a study referenced that shows that, and (2) if that were true, someone simply has to learn the language better. You can’t argue that some people’s inability to use a language is a reason to not use a feature of that language. That would argue that almost all syntax in languages should be stripped, and few languages (and especially computer languages) can survive that. Actually only Lisp survives that (give me just a pair of delimiters, and I can rule the world )

Also given Ruby uses CamelCase for classes, you already have a requirement to understand this kind of syntax aspect. So Ruby is presupposing the reader can read the syntax it is arguing the reader can’t read.

The standard, in different languages

A more interesting question is whether the “word and phrase standard” survives human-language change. Obviously the standard does not work “as written” if the language used is not a capital-capable language. And an obviously important language for that test is written Chinese (traditional or simplified). But actually the ‘underscores for phrases and parameters’ degrades with Chinese better than ‘underscores for words’. Chinese doesn’t require spaces for words to be apparent, and does not use spaces at all for that purpose (normally) — it is obvious where each word starts and ends without spacing because a word is only a couple characters long. So given words are apparent, the only thing left is to have phrases. Although unnatural to use underscores for phrases and parameters, it at least seems plausibly useful.

Admittedly I have not tried in depth to program in Chinese (Smalltalk/Agents by QKS had the ability way back but I only played with it a little) and have not found a study on it… so I can’t say for sure whether the underscore for parameters would make sense. But it is at least plausible it would make sense and it would make much more sense than underscore to separate (already separated) words.

Another plausible language to test against would be Hindi, but (I believe) most writers of Hindi in the computer field are also excellent English writers, so that is harder to argue for.

Could be hyphens

Note that the convention is totally happy with using ‘hyphens’ as word separators if the environment supports it.

   insert-at_values
   for-poles-other-than_do

Summary: Ruby has it wrong — We need CamelWords or hyphen-words

So I believe Ruby has it wrong and am very unhappy a modern language started 20 years after Smalltalk and several years after Dylan would get this kind of thing wrong. And I recommend moving the Ruby standard to the CamelWord_UnderPhrase standard, or allowing the hyphen and use the hyphen-word_under-phrase standard.

Tower of Hanoi — Rules on Rails

In part 6 we changed the algorithm of Tower Of Hanoi to work without requiring the stack — it instead “more naturally” put sufficient state and logic into the model that the model could start and stop and continue as needed. I believe with Ruby 1.8.x, this is required to have Rails be able to work with the Tower of Hanoi. So we should try it out and see how well it works

require 'hanoi_7'

class HanoiController < ApplicationController
  def say
    @hanoi = session[:hanoi]

    if (@hanoi == nil) then
      @hanoi = createHanoi
      session[:count] = 0
      session[:consoleLog] = ""
    end
    

    @hanoi.initApp(self)
    @isDone = @hanoi.doNextMove_IsDone()

    #clear the app because otherwise it will be part of the attempted serialization
    #could also override the marshaling code, but this is simpler
    @hanoi.initApp(nil)

    #clear out the session variable, but @hanoi is still valid through
    #the rest of this interaction
    session[:hanoi] = @isDone ? nil : @hanoi
    
    @count = session[:count] ||= 0
    @count += 1
    session[:count] = @count

    if (@isDone) then
      render(:action => 'say_done')
    end
  end

  def appendLog(outString)
    logger.info("Append to Log: "+outString)
    @consoleLog = session[:consoleLog] ||= "\n"
    @consoleLog = @consoleLog + outString + "\n"
    session[:consoleLog] = @consoleLog
  end

  def noteChange
    
  end
  
  def createHanoi
    hanoi = RulesTowerOfHanoi.new
    hanoi.initHeight(5)
    hanoi.setup_disks
    
    return hanoi
  end

  def getAsciiTowers
    result = ""
    lines = Array.new
    @hanoi.stacks.each_with_index do | eachStack, i |
      0.upto(10) do | j |
        eachDisk = eachStack[j]
        if (eachDisk == nil) then
          newLine = " "*12
        else
          newLine = eachDisk.to_s
        end

        newLine << " "*(12 - newLine.length)

        currentLine = lines[j] ||= ""
        lines[j] = currentLine+" "+newLine
      end
    end
    lines.reverse.each {|line| result += line + "\n"}

    return result
  end

end

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Foo <%= @page_title %></title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta http-equiv="refresh" content="1">
<%= javascript_include_tag :defaults %>
</head>

<body<% if @page_class %> class="<%= @page_class %>"<% end %>>

<h1>Tower of Hanoi (Move <%= @count %>) </h1>

It's <%= Time.now %>.
<br/>
Done = <%= @isDone %>
<br/>
Render =
<pre>
<%= controller.getAsciiTowers %>  
</pre>
Log =
<pre>
<%= @consoleLog %>
</pre>

</body>

Tower of Hanoi — With Rule Disks (and no stack)

The first passes at the Tower of Hanoi algorithm were all done with the algorithm being a recursive call on the stack. This is ‘true’ as an algorithm, but comes off as a bit unnatural for humans.

But it also has a problem in that the algorithm can not be ‘suspended’ in mid activity unless the language allows a feature (called a continuation) that can suspend the stack itself. Although Ruby is multi-threaded and running two threads works in RubyShoes, Rails does not work either with a stateful server (and multiple threads) or with continuations. At the end of each controller dispatch the session or the database has to have persisted all state. So we need to do something like formalizing the state of the Disks and Towers to make the Tower of Hanoi work with Rails.

Also, the Smalltalk code in this section was among the most ‘closure-oriented’, so this helps show how that maps to Ruby.

You aren’t capitalizing right?

Before continuing into the code, people should realize I actively object to Ruby’s choice to have only one ‘word’ delimiter by convention. See my article Ruby Naming Convention Failure for details and the naming conventions I use, especially for methods. But the quick summary is:

• I use CamelCase for combining words into a ‘part’ of a method name or variable name
• I use an underscore as a placeholder for the parameters of the method
• I use an underscore to break up a phrase into logical parts

If Ruby supported some other word delimiter than underscore (say hyphen “-” or “:”), I would be agnostic to dropping the CamelCase, but without that second word delimiter, dropping CamelCase is a losing proposition in expressiveness. In a team setting we might have to discuss this, but in this case this is my code alone… and my standard actually makes it easier to convert to-from Smalltalk, Ruby, Flex, Java, etc. The standard works cleanly with all of them.

Tower…

To migrate to the Rules version of the HanoiTower, it is easiest to start with the Disks themselves.

RulesHanoiDisk

A Rules based HanoiDisk just needs to be able to say “Can I move somewhere” and “If so, where”. It does this in collaboration with the Tower. “@tower” is now an instance variable that every Disk has set when it is created. By using an instance variable, it is cleaner than using class variables (we can have multiple towers at the same time) and it works under Ruby serialization/marshalling.

class RulesHanoiDisk < AnimatedHanoiDisk
  def hasLegalMove() 
    @towers.forPolesOtherThan_do(self) do | eachTopDisk |
      if (eachTopDisk.width  > self.width) then return true end
    end
    return false
  end

  def bestMove()
    @towers.forPolesOtherThan_do(self) do | eachTopDisk |
      if ( (eachTopDisk.width > self.width) && (eachTopDisk.pole != @previousPole) ) then return eachTopDisk end
    end
    return nil
  end

  def move_upon(destination)
    @previousPole = @pole

    super(destination)
  end

end

Among the interesting things with the new RulesHanoiDisk is the extensive use of Blocks. By using Blocks, we can iterate over the collection of stacks without creating new collections. The Disk and the Tower collaborate to create custom iterators with minimal code. See RulesTowerOfHanoi for the example.

RulesTowerOfHanoi

class RulesTowerOfHanoi < AnimatedTowerOfHanoi
  def initHeight(height)
    @height = height

    return self
  end

  def move_tower(height, fromPin, toPin, usingPin)
    while (!doNextMove_IsDone()) do end
  end
  
  def createDisk()
    result = RulesHanoiDisk.new
    result.setupTowers(self)
    
    return result
  end

  def doNextMove_IsDone()
    @currentDisk = decide()
    
    @stacks[@currentDisk.pole-1].pop()
    @stacks[@destinationDisk.pole-1].push(@currentDisk)
    @currentDisk.move_upon(@destinationDisk)
    
    @oldDisk = @currentDisk
    
    @app.noteChange if @app

    return isAllOnOneTower()
  end

  def isAllOnOneTower()
    foundStack = @stacks.detect { |eachStack|  eachStack.size == @height }
    return foundStack != nil
  end

  def forTopsOtherThan_do(disk)
    @stacks.each do | eachStack |
      if (eachStack.empty?) then next end

      topDisk = eachStack.last
      if (topDisk == disk) then next end

      yield topDisk
    end
  end
  
  def forPolesOtherThan_do(disk)
    @stacks.each_with_index do | eachStack, i |
      if (i == disk.pole-1) then next end;

      topDisk = if (eachStack.empty?) then @mockDisks[i] else eachStack.last end;

      yield topDisk
    end
  end

  def decide
    forTopsOtherThan_do(@oldDisk) do | eachDisk |
      if (eachDisk.hasLegalMove) then
        @destinationDisk = eachDisk.bestMove

        return eachDisk
      end
    end
  end
  
end

Tower of Hanoi — With Rule Disks (and no stack)

The first passes at the Tower of Hanoi algorithm were all done with the algorithm being a recursive call on the stack. This is ‘true’ as an algorithm, but comes off as a bit unnatural for humans. But it also has a problem in that the algorithm can not be ‘suspended’ in mid activity unless the language allows a feature (called a continuation) that can suspend the stack itself. For a multi-threaded language, this inability to suspend may not be a problem because you could create one thread for the algorithm and another thread to listen for whenever a new (interesting) change in state occurs. This is how the RubyShoes version works: the algorithm is in a new thread separate from the GUI thread (otherwise things behave badly). Similarly, the Smalltalk-80 GUI is being drawn in a different thread than the main execution thread. But in many circumstances even this multi-thread version would not work: say you have a client-server version (e.g. Rails) or want to pause/suspend the execution of the 100-tall tower of hanoi. And finally, if you only have a single-threaded language like Flex, things just don’t work at all for intermediate renderings unless you can make the algorithm not be dependent on the call stack.

Tower of Hanoi — With Rule Disks (and no stack) — Flex

I think it is easiest to work up from the Disk perspective, although see the book for a different flow. The main changes to HanoiDisk are to have it be able to figure out whether it has any legal moves, and what the bestMove (next move) would be. To do each of these, the disk needs to communicate back with the towers. In the Smalltalk code this was done through a Class Variable, but it is far simpler and more scalable to do this through instance variables: each Disk needs to know what tower it belongs to.

HanoiDiskRules

package {

public class HanoiDiskRules extends HanoiDisk {
    protected var my_previousPole : Number;
    protected var my_towers : AnimatedRulesTowerOfHanoi;
    
    public function setupTowers(towers : AnimatedRulesTowerOfHanoi) : void {
        my_towers = towers;
    }
    
    public function hasLegalMove() : Boolean {
        var otherTops : Array = my_towers.selectPolesOtherThan(this);
        for (var i:int = 0; i<otherTops.length; i++) {
            var eachTopDisk : HanoiDisk = otherTops[i];
            if (eachTopDisk.width > this.width) return true;
        } 
        return false;
    } 
    
    public function bestMove() : HanoiDisk {
        var otherTops : Array = my_towers.selectPolesOtherThan(this);
        for (var i:int = 0; i<otherTops.length; i++) {
            var eachTopDisk : HanoiDisk = otherTops[i];
            if ( (eachTopDisk.width > this.width) && (eachTopDisk.pole != my_previousPole) ) return eachTopDisk;
        } 
        return null;
    } 
    
    public override function moveUpon(destination : HanoiDisk) : void {
        my_previousPole = pole;
        
        super.moveUpon(destination);
    }
    
}

} //package

Compared to the Smalltalk version of this, the main difference is we are creating Array objects instead of passing a function into an iterator. Again this seems the more natural for Flex… but… it is starting to get annoying looking and has real performance impact, so later we should try to do an iterator + function-based version.

AnimatedRulesTowerOfHanoi (No Animation)

The change to the Tower code for Flex is two parts:

• Provide methods that support the rules that the smarter HanoiDiskRules has
• Drive the algorithm in a way to enable Flex to render the intermediary results

We can do these in two steps, with the current step focused on just the algorithm changes

package {

public class AnimatedRulesTowerOfHanoi extends AnimatedTowerOfHanoi {
    protected var my_oldDisk : HanoiDisk;
    protected var my_currentDisk : HanoiDisk;
    protected var my_destinationDisk : HanoiDisk;

    protected override function moveTower(height : int, fromPin : *, toPin : *, usingPin : *) : void {
        //Now that the disks know all the rules... we can ignore all the arguments!

        while (!doNextMove_IsDone) {};
    } 

    protected function doNextMove_IsDone() : Boolean {
        my_currentDisk = this.decide();
        
        (my_stacks[my_currentDisk.pole-1] as Array).pop();
        (my_stacks[my_destinationDisk.pole-1] as Array).push(my_currentDisk);
        my_currentDisk.moveUpon(my_destinationDisk);
        
        my_oldDisk = my_currentDisk;
        
        my_view.noteChange();
        
        return isAllOnOneTower();
    }
    
    protected function isAllOnOneTower() : Boolean {
        for (var i:int = 0; i<my_stacks.length; i++) {
            var eachStack : Array = my_stacks[i];
            if (eachStack.length == my_height) return true;
        }
        return false;
    }
    
    public function selectTopsOtherThan(disk : HanoiDisk) : Array {
        var result : Array = new Array();
        for (var i:int = 0; i<my_stacks.length; i++) {
            var eachStack : Array = my_stacks[i];
            
            if (eachStack.length == 0) continue;
            
            var topDisk : HanoiDisk = eachStack[eachStack.length-1];
            if (topDisk !== disk) {
                result.push(topDisk);
            }
        }
        return result;
    }
    
    public function selectPolesOtherThan(disk : HanoiDisk) : Array {
        var result : Array = new Array();
        for (var i:int = 0; i<my_stacks.length; i++) {
            var eachStack : Array = my_stacks[i];
            
            if (i == disk.pole-1) continue;
            
            if (eachStack.length == 0)  {
                result.push(my_mockDisks[i]);        
            } else {
                var topDisk : HanoiDisk = eachStack[eachStack.length-1];
                result.push(topDisk);
            }
        }
        return result;
    }
    
    protected function decide() : HanoiDisk {
        var tops : Array = selectTopsOtherThan(my_oldDisk);
        for (var i:int = 0; i<tops.length; i++) {
            var movingDisk : HanoiDiskRules = tops[i];
            if (movingDisk.hasLegalMove()) {
                my_destinationDisk = movingDisk.bestMove();
                
                return movingDisk;   
            }
        }
        //This should never happen
        return null;
    }
    
    protected override function createDisk() : HanoiDisk {
        var result : HanoiDiskRules = new HanoiDiskRules();
        result.setupTowers(this);
        return result;
    }
}

} //package

As mentioned in HanoiDiskRules section, the main annoyance of this particular implementation of the new algorithm compared to Smalltalk is having to create intermediate array objects just to communicate between the Disk and the Tower.

But things should work again. Except we will still get only one rendering because the whole algorithm is executed in one call within a “while” loop.

Tower of Hanoi — With Rule Disks and Correct Animation — Flex

To make things work in Flex now, all we do is have to unwrap the immediacy [single call stack] of the while loop. Instead of calling each ‘doNextMove’ immediately, we will wait for an event. That event could be anything, like clicking a button or the server sending a response. Each time we get an event, we will do the next step. To be easy to present and view, we will make the events be driven by a simple timer. Each time the timer fires an event, we will do the next step. Repeating this until we are done.

The only method changes are to ‘moveTower’ and to ‘handleTimer’. Everything else works just the way it was.

AnimatedRulesTowerOfHanoi (No Animation)

package {
    import flash.events.TimerEvent;
    import flash.utils.Timer;
    

public class AnimatedRulesTowerOfHanoi extends AnimatedTowerOfHanoi {
    protected var my_oldDisk : HanoiDisk;
    protected var my_currentDisk : HanoiDisk;
    protected var my_destinationDisk : HanoiDisk;

    protected var my_timer : Timer;
    
    protected override function moveTower(height : int, fromPin : *, toPin : *, usingPin : *) : void {
        //Now that the disks know all the rules... we can ignore all the arguments!

        my_timer = new Timer(300)
        my_timer.addEventListener(TimerEvent.TIMER, handleTimer);
        my_timer.start();
        
    } 

    public function handleTimer(evt:TimerEvent):void {
        var isDone : Boolean = doNextMove_IsDone();
        
        if (isDone) {
            my_timer.stop();
            my_timer = null;
        }
    }
    
        
    
    
    protected function doNextMove_IsDone() : Boolean {
        my_currentDisk = this.decide();
        
        (my_stacks[my_currentDisk.pole-1] as Array).pop();
        (my_stacks[my_destinationDisk.pole-1] as Array).push(my_currentDisk);
        my_currentDisk.moveUpon(my_destinationDisk);
        
        my_oldDisk = my_currentDisk;
        
        my_view.noteChange();
        
        return isAllOnOneTower();
    }
    
    protected function isAllOnOneTower() : Boolean {
        for (var i:int = 0; i<my_stacks.length; i++) {
            var eachStack : Array = my_stacks[i];
            if (eachStack.length == my_height) return true;
        }
        return false;
    }
    
    public function selectTopsOtherThan(disk : HanoiDisk) : Array {
        var result : Array = new Array();
        for (var i:int = 0; i<my_stacks.length; i++) {
            var eachStack : Array = my_stacks[i];
            
            if (eachStack.length == 0) continue;
            
            var topDisk : HanoiDisk = eachStack[eachStack.length-1];
            if (topDisk !== disk) {
                result.push(topDisk);
            }
        }
        return result;
    }
    
    public function selectPolesOtherThan(disk : HanoiDisk) : Array {
        var result : Array = new Array();
        for (var i:int = 0; i<my_stacks.length; i++) {
            var eachStack : Array = my_stacks[i];
            
            if (i == disk.pole-1) continue;
            
            if (eachStack.length == 0)  {
                result.push(my_mockDisks[i]);        
            } else {
                var topDisk : HanoiDisk = eachStack[eachStack.length-1];
                result.push(topDisk);
            }
        }
        return result;
    }
    
    protected function decide() : HanoiDisk {
        var tops : Array = selectTopsOtherThan(my_oldDisk);
        for (var i:int = 0; i<tops.length; i++) {
            var movingDisk : HanoiDiskRules = tops[i];
            if (movingDisk.hasLegalMove()) {
                my_destinationDisk = movingDisk.bestMove();
                
                return movingDisk;   
            }
        }
        //This should never happen
        return null;
    }
    
    protected override function createDisk() : HanoiDisk {
        var result : HanoiDiskRules = new HanoiDiskRules();
        result.setupTowers(this);
        return result;
    }
}

} //package

Comments

Tower of Hanoi — With Graphics

To follow the flow of code progress within “A Taste of Smalltalk”, we next need to include a graphical representation of the disks and their movement between the poles. Flex lives inside a Flash player (or app), so it is inherently capable of doing sophisticated graphics. Actually it is hard to ‘contain’ yourself to just doing the simplest possible thing when animating sprites around the screen is very easy. But to try to compare Flex to Ruby and Smalltalk, we want to keep things in about the same ballpark — and again study how different languages work with the same problem.

Tower of Hanoi — With Graphics — Flex

Given our Flex version is already in a graphics environment, and the model (TowerOfHanoi) is already aware of having to talk the View, the changes are relatively minimal to get things working. We need to render the disks in the Application/View and we need to notify the view whenever the model changes.

Main Application

To add rendering in, we just create a render canvas area and then create the UIComponents (shapes) on each redraw. Normally we would be more likely to animate a single set of disks (vs. destroying them and recreating them), which would be both better in performance and be _much cooler_, but this matches the RubyShoes version better.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical"
	creationComplete="handleCreationComplete()"
>
<mx:Script>
    <![CDATA[
        import mx.core.UIComponent;
        var my_model : AnimatedTowerOfHanoi;
    
        function handleCreationComplete() : void {
            Array.prototype.first = function():Object { return this[0]; }

            my_model = new AnimatedTowerOfHanoi();
            my_model.initView(this);
        }
        
        function handleDoItClicked() : void {
            logToConsole("\n=== Doing a Hanoi tower "+vTowerInput.text+" tall\n");
            my_model.doHanoi(new Number(vTowerInput.text));
        }
        
        public function logToConsole(string : String) : void {
            vConsole.text = vConsole.text+string;
        }
        
        public function noteChange() : void {
            vRenderArea.removeAllChildren();
            
            var stacks : Array = my_model.getStacks();
            for (var i : int = 0; i<stacks.length; i++) {
                var eachStack : Array = stacks[i];
                var poleCenterX : Number = i*100 + 50;
                
                for (var j:int = 0; j<eachStack.length; j++) {
                    var eachDisk : HanoiDisk = eachStack[j];

                    var diskHeight : int = 180 - (j * 15);
                    var diskWidth  : int = eachDisk.width * 10;
                    
                    var eachShape : UIComponent = new UIComponent();
                    eachShape.graphics.beginFill(0xA00000);
                    eachShape.graphics.drawRect(poleCenterX - diskWidth / 2, diskHeight, diskWidth, 10);
                    
                    vRenderArea.addChild(eachShape);
                } 
            } 
        }
    ]]>
</mx:Script> 
<mx:HBox>
    <mx:Text text="How tall a tower?" />
    <mx:TextInput id="vTowerInput" />
    <mx:Button label="Do It" click="handleDoItClicked()" />
</mx:HBox>  
<mx:Canvas id="vRenderArea" width="300" height="200" borderStyle="solid" />
<mx:TextArea id="vConsole" width="100%" height="100%" />
</mx:Application>

AnimatedTowerOfHanoi

The AnimatedTower just needs to send out change events (via a simple callback vs. true event listeners that are in Flex).

package {

public class AnimatedTowerOfHanoi extends ModeledTowerOfHanoi {
    protected override function setupDisks() : void {
        super.setupDisks();
        
        my_view.noteChange();
    }
    
    public function getStacks() : Array {
        return my_stacks;
    }

    protected override function moveDisk(fromPin : *, toPin : *) : void {
        super.moveDisk(fromPin, toPin);
        
        my_view.noteChange();
    }
}

} //package

Super Easy…But doesn’t work

Well, that was really easy… except it doesn’t really work You can only see the final result of all the nice disks on the last stack. None of the intermediary steps before this last rendering are shown at all.

Clearly we are missing something… where is the “Sleep” equivalent? If we could add a ‘sleep’ then everything would work right? Unfortunately both “No” and “NO!”. When Flex/Flash are running user code, they are doing it between screen renderings and a bunch of other tasks Flash does. So you can’t just keep rendering things in the same thread (same stack) and have any of that be visible except the last version. If you could ‘sleep’, you would just make Flash pause for no good reason.

The solution is to do each rendering on some kind of event. Something simple like do the next step of the hanoi algorithm every 0.3 seconds. That sounds easy but: (1) Flex doesn’t have continuations either so you can’t just ‘pause’ the stack and (2) The current hanoi algorithm is completely stack based.

Fortunately the fix is both “not that hard” and also happens to be the next chapter of “A Taste of Smalltalk” called “An Algorithm for the Rest of Us”. So for the moment, lets punt on getting the animation in Flex right until we get to the next part.

What’s Next

A new non-stack algorithm.

Tower of Hanoi — With Model Objects

The book “A Taste of Smalltalk” jumps from showing a single ‘TowerOfHanoi’ object to both adding in Disk model objects and putting on a graphical representation of those Disk objects. Even though Flex has no issue with graphics, I want to separate these two changes both to match Ruby and because the changes are logically somewhat separate. So first we can put in Disk objects and study that change. After that, we can go into the GUI code.

The Code

ModeledTowerOfHanoi

package {

/**
 * A ModeledTowerOfHanoi is the TowerOfHanoi algorithm
 * but it keeps track of the state of the Disks
 * with actual objects.  This makes it suitable for
 * model-based behavior (say tracking moves, animation or
 * other event listening) on top of those Disks
 */
public class ModeledTowerOfHanoi extends TowerOfHanoi{
    protected var my_height : Number;
    protected var my_mockDisks : Array;
    
    public override function doHanoi(height : int) : void {    
        my_height = height;
     
        setupDisks();
        
        logToConsole("\n\nStart\n");
        printStacks();

        logToConsole("\n\nMoves\n");
        moveTower(my_height, 1, 3, 2);
        
        logToConsole("\n\nResult\n");
        printStacks();
    }
    
    protected function setupDisks() : void {
        my_stacks = new Array();
        for (var i:int = 0; i<3; i++) {
            my_stacks.push(new Array());
        }
        
        var firstStack : Array = my_stacks.first(); //[0];
        for (var j:int = 0; j<my_height; j++) {
            firstStack.unshift(new HanoiDisk().initWidth_pole(j,1));
        }
        
        my_mockDisks = new Array();
        for (var k:int = 0; k<3; k++) {
            my_mockDisks[k]=new HanoiDisk().initWidth_pole(1000,k);
        }
    }
    
    protected function printStacks() : void {
        for (var i:int = 0; i<my_stacks.length; i++) {
            var eachStack : Array = my_stacks[i];
            logToConsole("   <stack>\n");
            for (var j:int = eachStack.length-1; j>=0; j--) {
                var eachDisk : * = eachStack[j];
                logToConsole(eachDisk.toString()+"\n");        
            }
            logToConsole("   </stack>\n");
        }
    }
        

    protected override function moveDisk(fromPin : *, toPin : *) : void {
        var supportDisk = (my_stacks[toPin-1].length == 0) ? my_mockDisks[toPin-1] : my_stacks[toPin-1][0];
        
        var disk : HanoiDisk = my_stacks[fromPin-1].pop();
        my_stacks[toPin-1].push(disk);
        
        disk.moveUpon(supportDisk);
        
        logToConsole(disk + " moved " + fromPin + "->" + toPin+"\n");
    }
    
    public function logToConsole(string : String) {
        my_view.logToConsole(string);
    }
    
}

} //package

HanoiDisk

package {

public class HanoiDisk {
    protected const CONST_asciiA : Number = "A".charCodeAt();

    public var width : Number;
    public var pole : Number;
    
    protected var my_name : String;
    protected var my_moveCount : Number = 0;
    
    public function initWidth_pole(aWidth : Number, aPole : Number) : HanoiDisk {
        width = aWidth;
        pole = aPole;
        
        if (width < 1000) {
            my_name = "Disk-#"+String.fromCharCode(CONST_asciiA+width);
        } else {
            my_name = "Base-#"+pole;
        }
        
        return this;
    }
    
    
    public function toString() : String {
        return my_name+"("+my_moveCount+")";
    }    

    public function moveUpon(destination : HanoiDisk) : void {
        pole = destination.pole;
        my_moveCount++;
    }
    
}

} //package

I believe the following are the most interesting aspects:

1. Public Attributes (which may be wrapped or unwrapped instance variables)
2. Explicit ‘override’
3. Explicit return values

Public Attributes

Flex allows you to have attributes that are either (1) just instance variables or (2) one or a pair of ‘set’ and ‘get’ accessors. The notation of access looks the same, so it is up to the receiver/implementer to decide whether ‘wrapping’ is necessary. Although the Macro approach of Ruby is nicer than having to do add accessors manually (or even ‘refactor’ them in with a tool), the Flex approach is by far the best for this kind of situation. The language/compiler actually understands the intent of the programmer (declaratively) vs. running through a macro and the results just happen to be the same.

Note that Flex goes beyond simple public attributes and can attach notification capabilities on top of it.

Explicit ‘override’

Flex and ActionScript again clearly try to help the programmer avoid making a mistake, in this case by making sure code _knows_ it is overriding inherited code and that within that override you have to consider what the superclass wants, whether you need to call ‘super’, etc.

Explicit return values

Flex enables you to avoid specifying the type of a return value (defaulting to ‘Any’), but you have to decide whether you are going to return anything or nothing at all. And if you are going to return anything, you need to explicitly say what you are going to return.

As I mentions in Part 4 of a Taste of Ruby, this approach is clearly the best — actually better than what I mentioned there. So then returning ‘null’ by default becomes a good second best (no language so far mentioned), Returning ‘self’ by default is third best (Smalltalk). And Ruby returning of “whatever happens to be returned by the last statement” is a distant fourth.

What Next

Now onto the GUI itself.

Tower of Hanoi — With A Real Object

The first two examples were not really object-based. They are purely procedural, the algorithm is expressed completely recursively, and execution state is maintained on the call stack. This works fine if we are just ‘tracing’ the algorithm, but it does not let us show the state of the towers at any given time. We also don’t see much in the way of real objects. By adding the state of the towers in, we now have a reason to have stateful objects and new Classes of objects to maintain that state. The added code with some explanation is in Chapter 4, Page 45.

TowerOfHanoi

The TowerOfHanoi main class is now able to be a pure ActionScript class, so it looks much cleaner and formats nicely now. The only additional feature it needs (compared to say the Smalltalk or Ruby version) is a reference to its View so it can print into the Console of that view. I could actually just use ‘Application.application’ to get the outer view, but this is cleaner, more scalable, and makes it clearer what is happening [even though many people like to cheat with those kinds of Globals].

package {

public class TowerOfHanoi {
    protected const CONST_asciiA : Number = "A".charCodeAt();
    
    protected var my_view : *;
    protected var my_stacks : Array;
    
    public function initView(view : *) : void {
        my_view = view;
    }
    
    public function doHanoi(height : int) : void {    
        my_stacks = new Array();
        for (var i:int = 0; i<3; i++) {
            my_stacks.push(new Array());
        }
        
        var firstStack : Array = my_stacks[0];
        for (var j:int = 0; j<height; j++) {
            firstStack.unshift("Disk-#"+String.fromCharCode(CONST_asciiA+j));
        }
        
        moveTower(height, 1, 3, 2);
    }
        

    protected function moveTower(height : int, fromPin : *, toPin : *, usingPin : *) : void {
        if (height > 0) {
            moveTower(height-1, fromPin, usingPin, toPin);
            moveDisk(fromPin, toPin);
            moveTower(height-1, usingPin, toPin, fromPin);
        }
    } 
    
    protected function moveDisk(fromPin : *, toPin : *) : void {
        var disk = my_stacks[fromPin-1].pop();
        my_stacks[toPin-1].push(disk);
        
        my_view.logToConsole(disk + " moved " + fromPin + "->" + toPin+"\n");
    }
    
}

} //package

Main Application

The main Application is now clean of model code and just (1) holds onto the outer model and (2) provides view services to others. I made logToConsole public so people could identify what is meant to be used by others vs. what is not. Ultimately ‘logToConsole’ could be put into an interface to make it clearer that is all the ‘TowerOfHanoi’ needs from its view.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical"
	creationComplete="handleCreationComplete()"
>
<mx:Script>
    <![CDATA[
        var my_model : TowerOfHanoi;
    
        function handleCreationComplete() : void {
            my_model = new TowerOfHanoi();
            my_model.initView(this);
        }
        
        function handleDoItClicked() : void {
            logToConsole("\n=== Doing a Hanoi tower "+vTowerInput.text+" tall\n");
            my_model.doHanoi(new Number(vTowerInput.text));
        }
        
        public function logToConsole(string : String) : void {
            vConsole.text = vConsole.text+string;
        }
    ]]>
</mx:Script> 
<mx:HBox>
    <mx:Text text="How tall a tower?" />
    <mx:TextInput id="vTowerInput" />
    <mx:Button label="Do It" click="handleDoItClicked()" />
</mx:HBox>    
<mx:TextArea id="vConsole" width="100%" height="100%" />
</mx:Application>

Comments

By moving the ActionScript portion out of the main Application XML, the syntax becomes clearer. Another feature of Flex that is starting to show is that we can document and compile-time verify visibility (as needed), contractual interfaces (as needed), etc. But we can also leave them off and things work fine.

We do need to document the existence of instance variables, local variables, and methods of whatever types we use (e.g. ‘self’ / ‘this’) or the compiler will complain. I believe this is far better (most of the time) than leaving that as a pure runtime issue and having typos potentially take significant time to debug. And this does not interfere with things being ‘dynamic’ (‘duck typed’) in most cases although it is related to some meta-language capabilities.

Going into the Flex code itself, we can see a stronger relationship to ‘C’ style control structures and not the higher-level block/closure structuring of things. Although iterators and Functions are available in Flex/AS, they are not as natural in the language as in Smalltalk or Ruby because they don’t work well with collections (as defined in the current API) and are just a bit too verbose in general. You could modify (monkey-patch) collections, but then the compiler would not understand the new functionality. Although that is no worse than in Java/Ruby, it would be unusual in the community. Maybe if Adobe adds it to AS4 just to be cross-language similar, it would be more natural. But I didn’t want to augment the existing classes just to have the language match another language’s idioms

Examples of this kind of Monkey-Patch are:

• RocketBoots
• Kirupa

A minor note, the CharCode conversion is actually a Unicode conversion. So you can put pretty much any character in the world languages you want to in there For example, try it with ’50023′ for the CONST value.

Where Next?

Next we should go to Chapter 5 (Animating the Program) — Page 64. This involves some graphic work for the ‘model’ aspects to be realistic, and for Flex this is not at all difficult, but I will follow the same pattern of ‘Parts’ that I did with Ruby, so the next Part is just changing to having real Domain Model Objects (vs. the UI Model separation that occurred above for TowerOfHanoi vs the Application)

Tower of Hanoi — Procedural With Input

The second example from “A Taste of Smalltalk” is in Chapter 3, page 36 and does basic IO. Except that Smalltalk-80 includes a Windowing graphics system so it can automatically open Dialogs and other things. Fortunately Flex includes a Windowing system too, and can easily open up dialogs. Opening up a Dialog might match the Smalltalk example the best, but given Flex is already running within a Window, opening up an extra dialog is a bit artificial. Instead we can just add an input field for the value and a button to kick off the Hanoi.

Tower of Hanoi — Procedural With Input — Flex

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical"
	creationComplete="handleCreationComplete()"
>
<mx:Script>
    <![CDATA[
        function moveTower(height : int, fromPin : *, toPin : *, usingPin : *) : void {
            if (height > 0) {
                moveTower(height-1, fromPin, usingPin, toPin);
                moveDisk(fromPin, toPin);
                moveTower(height-1, usingPin, toPin, fromPin);
            }
        } 
        
        function moveDisk(fromPin : *, toPin : *) : void {
            vConsole.text = vConsole.text+fromPin + "->" + toPin+"\n";
        }
        
        function handleCreationComplete() : void {
            //Don't need to do anything anymore
        }
        
        function handleDoItClicked() : void {
            vConsole.text = vConsole.text+"\n=== Doing a Hanoi tower "+vTowerInput.text+" tall\n";
            moveTower(new Number(vTowerInput.text), 1, 3, 2);        
        }
    ]]>
</mx:Script> 
<mx:HBox>
    <mx:Text text="How tall a tower?" />
    <mx:TextInput id="vTowerInput" />
    <mx:Button label="Do It" click="handleDoItClicked()" />
</mx:HBox>    
<mx:TextArea id="vConsole" width="100%" height="100%" />
</mx:Application>

To replace the dialog (in Smalltalk) or the command line request (in Ruby), we just create a horizontal row of a question label, an input field, and a Do It button. Whenever a user clicks Do It, it takes the current value of the field and runs the Hanoi algorithm.

This is both pleasingly simply and also has the added benefit that we produced an interactive tool: you can just keep typing new numbers into it and it will give you new results.

Comments

Flex is highly capable with user input and interactivity. It has a cleaner / simpler UI model than Smalltalk (IMO), which is good given we have had about 30 years of working with UIs to take things forward. Compared to Ruby, Flex is as easy as RubyShoes for simple things like this example.

Where Next?

Next we should go to Chapter 4 — Page 44. The Third Example (with Real Hanoi Classes)