|
A pattern detector tool takes a program as an input and finds all instances of certain patterns inside this program. Here is a list of some of the challenges that need to be tackled:
- Space/Time behavior. This tool is a batch processor, so it is likely to either: (a) exhaust the memory; or (b) exhibit poor performance. The underlying data model should support intelligent, seamless, caching.
- Vendor lock-in. We want to the tool's business logic to be decoupled from the low-level class inspection code.
- Object identity. Suppose that c1 and c2 represent two different input classes that belong to the same package. It is natural to expect that the following assertion is true: c1.getPackge() == c2.getPackge(). This is not trivial to achieve in face of caching or if the package is defined in two distinct jar files. Similarly we expect all instances of an instantiated parametric type to be represented by a single object.
- Family polymorphism. An object-oriented program is essentially a graph where the nodes represent types, methods, fields, packages, etc. and the edges represent various relationships (declares, extends, invokes, etc.). A system of classes that represents such a graph is inherently covariant:
class Type {
...
public Method getMethods() { ... }
public Type getSuperClass() { ... }
}
class Method {
...
public Type getDeclaringType() { ... }
public boolean canOverride(Method m) { ... }
}
Implementing such a system in a statically typed language
while avoiding coupling with the low-level classes is not
trivial (See Erik Ernst's Family Polymorphism paper,
http://www.daimi.au.dk/~ ... ers/fampol.ps.gz ; Garcia
et-al, http://faculty.cs.tamu.e ... apers/cmp_gp.pdf).
In particualr, The canOverride(Method m) method
is a binary method and thus especially challenging.
Written by Itay Maman (http://www.cs.technion.ac.il/~imaman)
|
