Open yossigil opened 8 years ago
I do not see those commits coming!
@dngreenst : you should have started with a commit, with unit tests that check that the function is definend and a bunck of @Ignore non-working yet tests.
We're using MakeAST.COMPILATION_UNIT to create ASTNodes for the tests (that are not connected to the main AST).
Have we missed a more elegant way of doing this?
A few weeks ago we wrote a full bunch of code examples for testing the env... Now while writing the actual tests I thought that we should somehow integrate those code examples instead of writing every single piece of code as a String. Am I right?
Sure you would. You do the same recursive scanning for implementing these two methods. The whole purpose of these methods is: say your are given a function f with argument X. You want to change X to Y. To be able to do so, you must check that the f does not define Y and that it uses no variable named Y.
For the testing, you would need your @Annotation. For real production, these two function will serve. They are interchangeable.
We found a method for traversing ASTNode:
for (ICompilationUnit unit : mypackage.getCompilationUnits()) { IType[] types = unit.getTypes(); for (int i = 0; i < types.length; i++) { IType type = types[i]; IMethod[] methods = type.getMethods();
But I think it is not exactly what you meant... in this case we suppose we get a CompilationUnit, which extends ASTNode but then not every ASTNode will be suitable to use.
Could you give us some wire end?
Study the methods in classes wizard, step and hop. I believe you have a solution there. When you find it, document it. If it already documented, document another function
We think the return type of the functions should be some sort of ordered collection, and in my understanding Set isn't.. Should we use LinkedHashMap instead? It is an issue when checking the order of the names in the Environment
There is a LinkdeHashSet
One more implementation choice: We need to create new Map.Entry<>() but saw that java isn't supporting that. we found to options:
TreeMap<String,Information> m = new TreeMap<>(); m.put(s, i); testFlatENV.add(m.firstEntry());
public MyEntry(K key, V value) {
this.key = key;
this.value = value;
}
@Override
public K getKey() {
return key;
}
@Override
public V getValue() {
return value;
}
@Override
public V setValue(V value) {
V old = this.value;
this.value = value;
return old;
}
}`
We peaked the second
There is a problem with unmodifiable
for LinkedHashSet
- only Collection.unmodifiableSortedSet
and Collection.unmodifiableSet
exist.
@yossigil we have a little problem with Information equality check. For testing purposes, we would like to check equality in a more thorough manner than just checking if they belong to the same instance. I have implemented a equals() function to that end.
However, that means we also need hashCode to be overridden. To do that, I found
However, I am uncertain as to how to add that to the project.
EDIT no longer relevant.
@yossigil , we were thinking about the design of Environment.uses(ASTNode n)
and Environment.declares(ASTNode n)
. Some thoughts we wanted to run by you:
Environment.declaresUp(ASTNode n)
should look for declarations that appear above the current node n
. In other words, we should go over n
's ancesors, and the statements of these ancestors. Environment.declaresDown(ASTNode n)
should look for declarations that appear below the current node n
.Environment.UsesUp(ASTNode n)
Similar to Environment.declaresUp(ASTNode n)
, for uses.Environment.UsesDown(ASTNode n)
Similar to Environment.declaresDown(ASTNode n)
, for uses.The differences are right: something may be in the scope without being used. But, don't let bother your. Proceed with one definition, but make it right, clear and crisp. Then, when applications come, renaming is the major one, you can fine tune it, but you cannot fine tune a definition which was not clear initially.
No work for now
Dor: passing on to you. It is mostly done. If there is nothing more to do, close this
make the environment more useful in tippers.