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

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

    vranganath> No, it is not the structure of the constructor
    vranganath> you are exposing.  You are just explicating that
    vranganath> if the user extends ExceptionalUnitGraph, then
    vranganath> he/she will also need to initialize it.  It's
    vranganath> like a contract.  If this is the case, the
    vranganath> proposed solution for 2 step construction should
    vranganath> be fine. Also, as you said earlier, the users
    vranganath> should be given the choice to accept more freedom
    vranganath> with more responsibility.

It's not the 2-step construction that I am having misgivings
about.  It's my original decision to expose the fact that the
second step in construction consists of calls to

>     buildUnexceptionalEdges();
>     buildExceptionDests();
>     buildExceptionalEdges();
>     buildHeadsAndTails();

and inviting users to selectively override these methods that I'm
no longer sure is a good idea. 

    vranganath> Well, first, it is not a wrapper class as it's
    vranganath> behavior is different from that of the graph used
    vranganath> to construct it.  Second, this means if I am
    vranganath> interested in using the ExceptionalUnitGraph
    vranganath> interface then I cannot do so as I have an
    vranganath> UnitGraph on hand.  This leaves the only
    vranganath> solution, tweak the construction via a
    vranganath> ThrowAnalysis implementation.  However, if there
    vranganath> is any other form of modifications to be done to
    vranganath> the graph, how should they be accomplished?

What I realized after initially making my suggestion to override
buildExceptionalEdges() is that all the information used by
buildExceptionalEdges() is also available through the public
interface of ExceptionalUnitGraph, via
getExceptionalSuccsOf(), getExceptionalPredsOf(), and
getExceptionDests().

So your graph could create an ExceptionalUnitGraph, use the
public interface to get the information to build its own set of
edges, and either discard the ExceptionalUnitGraph or keep it
around for forwarding some requests to.  Then your
class would depend only on the get-() methods in
ExceptionalUnitGraph's interface; we're less likely to be tempted
to change these methods for querying the graph's state than the
substeps we use to establish that state.

It would even be possible to extend ExceptionalUnitGraph's
interface, without overriding selected steps in its constructor,
by using the data returned by the superclass constructor to
decide what edges you really need, and then replacing the maps
from Units to their successors and predecessors.  That
would require that the maps remain protected rather than
package-private, which is probably also proscribed by the
textbook warnings against ill-considered inheritance.

I'm just concerned that, because the substages in the
ExceptionalUnitGraph constructor were created for my own
convenience and not as the carefully planned basis for
inheritance by Soot clients, maybe it was a rash to invite you to
override the substages. Let me wait a little longer for input
before making a decision.