Re: is it wise to provide hooks to customize ExceptionalUnitGraph's constructors?

[John Jorgensen <jorgnsn@lcd.uregina.ca>]

    olhotak> Hi John...  In general, I try to discourage placing
    olhotak> a lot of code in the constructor or in methods
    olhotak> called from the constructor (although this is a
    olhotak> common practice in Soot), because of the various
    olhotak> restrictions on constructors.  These include the
    olhotak> overriding restriction that you noted, as well as
    olhotak> the fact that a constructor cannot signal a failure
    olhotak> because it returns nothing. Doing lots in the
    olhotak> constructor can also be the source of subtle
    olhotak> bugs. For example, if the superclass constructor
    olhotak> calls method foo() and a subclass overrides foo(),
    olhotak> then foo() will be called before the subclass
    olhotak> constructor has finished, and the class invariant
    olhotak> may not have been established yet.

My concern was not really with the splitting out the 
initialize() method. Instead, I'm wondering if my previous
decision to make the substeps of ExceptionalUnitGraph overridable
was ill-considered, since it widens the class's interface to
include the substeps it uses to build the graph.

    olhotak> My advice is this: the constructor should establish
    olhotak> the class invariant, and nothing else. The class
    olhotak> invariant should be chosen to be simple enough that
    olhotak> it can be established in the constructor.

I'm not clear on what you mean by a class invariant.  Wouldn't
the properties that must hold for every instance of a CFG
class include things like "if a node is a conditional branch, its
successors will include the node it falls through to and the node
it branches to"?  Or are you referring to some narrower
structural properties, like "the set of all successors of a node
must equal the union of the sets of its exceptional and
unexceptional succeesors)?

    olhotak> When the amount of work to be done to build the
    olhotak> thing is substantial, my personal preference is to
    olhotak> split up the builder and the container into separate
    olhotak> classes, so that one may subclass one without the
    olhotak> other (see, for example, the CallGraph and
    olhotak> CallGraphBuilder). 

This sounds like a cleaner way to allow overriding selected
parts of the construction process. I'll take a look at 
the example.