[Soot-list] Structure of Soot (OO Design)

[Chris Pickett]

I think that Soot is particularly sticky as a target for refactoring 
because a lot of external source code depends on its API.  I also happen 
to think that the large number of Soot-dependent projects out there 
speaks volumes to its usability.

Certainly some internal cleanup could be done, but I think breaking the 
API for the sake of it is going to cause more harm than good.

Kyle, if you want to submit some refactoring patches based on the month 
of work you've done that would be great.

Cheers,
Chris

Prof. Laurie HENDREN wrote:
> Before we go on to bash on Soot more ...  I would like to say that
> many students have put in many hours in designing and implementing
> Soot.  Let us be very careful in acknowledging all of that work and
> also many of the good design decisions.
> 
>  Like any large system on which many people have worked it
> could likely do with some refactoring and cleanup.   However, many
> of the underlying decisions of the design were carefully taken and
> were intended to support an extensible framework that treats
> many IRs in a consistent fashion.
> 
> It IS very complex - but it contains quite a bit of functionality
> and it implements many complex ideas.
> 
> Laurie
> 
> 
> +-----------------------------------------------------------------
> | Laurie Hendren --- laurie.hendren at mcgill.ca
> | Associate Dean (Academic), Faculty of Science,
> | Dawson Hall, McGill University, 853 Sherbrooke St W,
> | Montreal QC H3A 2T6 Canada, 514-398-7179, fax 514-398-1774
> +----------------------------------------------------------------
> | For contact and home page info as Professor, Computer Science:
> | http://www.sable.mcgill.ca/~hendren   ---  hendren at cs.mcgill.ca
> | Research: http://www.sable.mcgill.ca  http://aspectbench.org
> +----------------------------------------------------------------
> 
> On Sat, 3 Jun 2006, Hayden Melton wrote:
> 
> 
>> > Thank you for putting a metric to how difficult it is to understand Soot
>>
>>>code. Over the last month I have been refactoring Soot beyond
>>>recognition, trying to isolate the optimization routines from the
>>>parsing and code generation. Soot feels as though every class depends on
>>>every other class; a huge ball of spaghetti where pulling on any strand
>>>pulls brings the whole ball with it.
>>>
>>>Your graph certainly verified my feeling.
>>
>>I'm glad the metric matches your intuition. It's been a bit of a mission
>>convincing some open-source developers of its usefulness! One problem i think
>>is that open source developers often understand the whole system they work on,
>>so understand what every class in a cycle does. But for a `newb' like myself to
>>understand their system it's very hard because everything's cyclically
>>dependent. I empathize with ya dude.
>>
>>
>>
>>Eric Bodden: I have made available the data that I used to generate those
>>graphs. Follow this link, scroll down to the table and download the zip file
>>for the latest version of Soot:
>>
>>http://www.cs.auckland.ac.nz/~hayden/corpus.htm
>>
>>You can use this information to show which files participate in the SCCs and
>>which have large transitive dependencies. In terms of actual refactoring
>>there's no silver bullet. The Azureus people used a move-method refactoring on
>>some static methods to break up some SCCs.
>>
>>My feeling is that classes with a high fanin that are involved in large SCCs are
>>a good place to start. Classes that are widely referenced are often
>>``low-level" classes and should not depend on ``high-level" classes. Look at
>>these and see if you can reduce their dependencies by extracting interfaces,
>>creating new classes, moving methods etc. There is a catalogue of refactorings
>>specifically for breaking cyclic dependencies in John Lakos's book
>>``Large-Scale C++ Software Design".
>>
>>/
>>Hayden
>>
>>
>>
>>
>>
>>
>>
>>>
>>>Hayden Melton wrote:
>>>
>>>
>>>>Hi all,
>>>>
>>>>
>>>>I’m a PhD student at the University of Auckland, New Zealand. As part of my
>>>>research I am doing empirical studies on a corpus of Java applications
>>>
>>>looking
>>>
>>>>at their (OO) design. If you are a developer of Soot you might be interested
>>>
>>>in
>>>
>>>>the metrics I have collected on it. They are available as graphs here:
>>>>
>>>>http://www.cs.auckland.ac.nz/~hayden/junitEvolution.htm
>>>>
>>>>There’s an explanation of what the graphs mean on my research page:
>>>>
>>>>http://www.cs.auckland.ac.nz/~hayden/research.htm
>>>>
>>>>Briefly, there are a lot of classes in Soot involved in a big (compilation)
>>>>dependency cycle (or to use the graph-theory term: strongly connected
>>>>component). I think this is bad, though it’s only one aspect of the quality
>>>
>>>of
>>>
>>>>a design. Other applications like ArgoUML and Azureus have exhibited this
>>>
>>>large
>>>
>>>>SCC characteristic too. As a result of my contact with the Azureus
>>>
>>>developers
>>>
>>>>they have begun refactoring Azureus.
>>>>
>>>>In any case, check it out if you’re interested in the design of Soot; or OO
>>>>Design and metrics in general.
>>>>
>>>>/
>>>>Hayden Melton
>>>>
>>>>_______________________________________________
>>>>Soot-list mailing list
>>>>Soot-list at sable.mcgill.ca
>>>>http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>>>
>>>>
>>>>
>>>
>>>
>>>--
>>>----------------------------------------------------------------------
>>>Kyle Lahnakoski                                       kyle at arcavia.com
>>>(416) 892-7784                                    Arcavia Software Ltd
>>>
>>>
>>
>>
>>
>>_______________________________________________
>>Soot-list mailing list
>>Soot-list at sable.mcgill.ca
>>http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>
> 
> 
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list