dozmus / csar Goto Github PK

This may be accomplished for renaming using a Renamable interface, which MethodStatement and MethodCallExpression will implement.

The change parameters equivalent will follow analogously.

By file name, and then by line number.

This will be done in QualifiedNameResolver, but potentially may require work in some other places too.

Some comments from our paper submission, which are worth considering:

Query Languages for program comprehesion is not a new topic and there are several interesting papers. Many commercial tools now integrate the work done earlier. I think comparison witth these tools is a critical missing piece of information from the paper. Here are some tools/approaches that authors would like to have a look at: CPPDepend [1], QL for source code analyis [2] and Moose[3]. Another point is that query language appears to be language-specific: final doesn't exist in C++, there are const and constexpr. So, may be a generic meta-model representing code entities and their qualifiers will be a better approach. Integrating syntax of all languages in the query language require too much work, IMO.

All the csar examples in the paper starts with the SELECT keyword. This suggests me that SELECT is redundant and not used, for me e.g. REFACTOR something TO something would be more logical than the current SELECT something REFACTOR something. It is also unclear where are the limitations of the language.

I think a more powerful solution would involve writing a query language which targets object-oriented languages in general, and then implementing that.

This requires more Thread.isInterrupted() checks.

The results of the OverriddenMethodsResolver are only used in searching for overridden methods. This means that can do not have to compute whether every single method is overridden or not, but rather just candidate results (i.e. methods whose descriptions match the query description, minus the overridden field).

This will increase performance.

Get the value using the token representing it in the parser.

This then leads to the removal of #methodIdentifier(Expression) and #methodIdentifierExpression(Expression).

• Display an input pane, with csar query input, run and cancel
• Display a results pane, analogous to inspection results, with two top-level drop downs: search and refactor
• Each displays number of results grayed out next to them
• Furthermore, on their drop-downs list the classes containing these results and the specific lines

Suppose we transform the parameters as follows: (float a, float b) -> (float... f).
It may make sense to not modify the method call arguments of said method, since they are still compatible.

The ANTLR4 grammar for Java 8 does not parse all kinds of method references.

They might be loaded automatically from a build file too, e.g. a build.gradle.

e.g. line width limit

This is trivial to multi-thread.

Parsing project source code (in csar-java) accounts for a large amount of the time taken.
It would be optimal to index the parsed source code, and update them as necessary.

This will require making a lot of the language constructs in csar-java no longer immutable, which is okay since some of them over time have become mutable, and thus making them all mutable would make more sense.

A possibly library for this is Kryo.

This will improve performance.

The current model is unsatisfactory because it required the creation of a method, which is used nowhere else in csar.

Fetch the snippets from the files directly.