Re: About revision 1407.... Again

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

>>>>> "vranganath" == Venkatesh Prasad Ranganath <vranganath@cox.net> writes:


    vranganath> I am not instantiating UnitGraph.  I am extending
    vranganath> it.  The extension is independent of the class'
    vranganath> abstractness but is rather dependent on the
    vranganath> published interface of the class.  So, I would
    vranganath> not be concerned if this class was not published
    vranganath> or if the constructor was deprecated in the last
    vranganath> release of Soot.  Instead, the API changed all of
    vranganath> a sudden and I am stuck.  Maybe I will be able to
    vranganath> recast my implementation to use the new
    vranganath> constructors with a sequence follow-up method
    vranganath> calls on the instance, but can we use the
    vranganath> available tools and deprecate parts of the
    vranganath> previously published interface of UnitGraph in
    vranganath> this release and remove them according to the
    vranganath> deprecation process suggested by Java community?

This is a ticklish problem.  I consulted about approaches to
ensure compatibility with CompleteUnitGraph, TrapUnitGraph, and
BriefUnitGraph, but neglected the possibility that people might
derive their own subclasses of UnitGraph.

Since the machinery for pruning exceptions in the new CFG
implementations doesn't easily permit them to coexist with the
old UnitGraph constructor, the only way to preserve backwards
compatibility which occurs to me offhand (but then, I have yet to
think about this for very long) would be to deprecate UnitGraph
as you suggest, and then give a completely new name to the
reimplementation. That might be what we need to do, but I wonder
if we can take a short cut...

The machinery for constructing all the old UnitGraph variants is
still available in the new classes, just reorganized. If you tell
me what parameters you feed to UnitGraph(), I can outline how to
get the same effect from the new classes.