[PRL] analysis of Demeter tools

[Jeffrey Palm]

Matthias Felleisen wrote:

> Send'em along. We're happy to give everyone a grade, and more than one :-)
> 
> On Mar 31, 2005, at 4:48 PM, Karl Lieberherr wrote:
> 
>> Hi Matthias:
>>
>> So DemeterJ's generated Java source code got bad reviews in your
>> analysis.
>>
>> Interfaces in DemeterJ are hidden in the *.beh files that your tools
>> don't analyze. A *.beh file defines a set of constraints in the form of
>> a set of traversal strategies that the class graph must satisfy. If you
>> don't satisfy this interface at compile time, you get an error message:
>> no path found.
>>
>> The AP Library should do better in your analysis. In the AP Library,
>> Doug uses interfaces to facilitate reuse of the traversal graph
>> algorithms.
>> But also the AP Library contains generated Java code which will reduce
>> our grade. :-)
>>
>> -- Karl

I'm not exactly what this tool is doing, but if you're looking at 
breaking the interface abstraction anything generated from the demeter 
tools should fail miserably, because of the generated visitor code. 
Also, I'd image anything using java collections would do the same.

I built a tool a couple years ago to analyze a similar thing and found 
the only way to get somewhat reasonable results was to not consider 
collections or any other idiom relying on down casting.  You should 
discount the generated visitor and focus on the human-written code if 
you look at the demeter tools.

Just a thought.
Jeff
-- 
Jeffrey Palm --> http://www.ccs.neu.edu/home/jpalm