This week's lab is a bit of a potpourri of topics... 

Quicksort

Quicksort is the most common sorting algorithm in use today.  In light of its technological impact, it's good to know how it works. 

...

The visitor system that HW11 uses allows you to give parameters to the visitor at the time that you use the visitor rather than having to imbed additional parameters inside the visitor as was done in many examples in class.   This means that the same visitor instance can be used in multiple situations with different input parameters.   To note however, when using anonymous inner classes, input parameter values are often not needed because the anonymous inner class already has access, via its closure, to most of the values it needs.    Input parameters are particularly useful for things such as accumulators however, which cannot be curried in.

===================================================================================================================

A Tale of Two Visitors

You were shown two different styles of writing visitors, with and without input parameters.    Why two different techniques?

The main reason:  because different people view the world in different manners and everyone's viewpoint has their strengths and weaknesses.

Here's a more technical breakdown:

Dr. Cartwright's No-input Parameter Visitor Style

Any necessary parameters for a visitor are handed to the constructor of the visitor and are saved in field(s) of the visitor to be used as the visitor executes.

Pros:

• Parameters of multiple types are easily handled.
• The host's accept method is simplified and maintains exactly the same call structure for any visitor.
• When using anonymous inner class implementations of visitors, most parameters are curried in via the anonymous inner class's closure, so parameter storage fields are often not necessary.

Cons:

• If the parameter value changes, e.g. for accululator algorithms, either one has to instantiate an entirely new instance of the visitor or take the risk of mutating the parameter storage field and hope that no one else is using the visitor. 
• Anonymous inner class implementations treat parameters that are invariant over the lifetime of the visitor equivalently to those that are varying from call to call.
• The design does not cleanly separate the variant nature of the parameters from the invariant nature of the processing algorithm that the vistior represents.
  

Dr. Wong's Vararg Input Parameter Visitor Style

Parameters for a visitor are handed to the vistior at execution time (when accepted by the host) via a variable input argument list (vararg).

Pros:

• The variant input parameters are cleanly separated from the invariant processing algorithm the vistior represents.   This enables many more visitors to be written as singletons.
• Input parameters with varying values, e.g. accumulator algorithms are easily handled without instantiating a new visitor instance or worrying about multiple usages of the visitor.
• The same visitor instance can be used simultaneously, e.g. in parallel taskings and in branching recursive algorithms. 
• Varargs allows varied numbers of parameter values to be handed to the same vistior, including none at all.
• Using anonymous inner class implementations allow the separation of parameters that are invariant over the lifetime of the visitor (curried-in values) vs. parameters that vary from call to call (input parameters). 

Cons:

• Parameters of different types are difficult to handle.
• Since the host's accept method allows any number of input parameters to be provided, it is impossible to tell if the correct number of input parameters has been passed.
• No parameter visitors are still required to declare an input parameter type (e.g. "Void...nu").
  

Who's "right"?   That depends on where you stand and what's important to you.    Perhaps neither.   You choose what's right for what you're trying to do at that moment.   There is no gospel, only defensible but non-absolute positions.