馃摑 Overall Description
API design
I currently noticed that CallGraph provides two different APIs with the same default implementation, CallGraph.getCalleesOfM() and CallGraph.getSuccsOf():
|
public Set<Method> getCalleesOfM(Method caller) { |
|
return callSitesIn(caller) |
|
.flatMap(cs -> getCalleesOf(cs).stream()) |
|
.collect(Collectors.toUnmodifiableSet()); |
|
} |
|
public Set<Method> getSuccsOf(Method node) { |
|
return callSitesIn(node) |
|
.flatMap(cs -> getCalleesOf(cs).stream()) |
|
.collect(Collectors.toUnmodifiableSet()); |
|
} |
The getSuccsOf seems straightforward to me, but the getCalleesOfM takes me a while to realize its meaning.
My question: Is this a deliberate design choice? What is the rationale behind this?
Mutable vs Immutable
The callgraphs seem to be mutable by design, i.e., by allowing adding nodes and edges to the callgraphs. This makes several callgraph related operations inefficient, such as querying the successors and predecessors of a node, where caching the results might be difficult.
However, many applications do not actually modify the callgraph (e.g., traversing the callgraphs when computing SCCs). Is there any chance that Tai-e will introduce ImmutableCallGraph or something like that?
馃幆 Expected Behavior
Just out of curiosity
馃悰 Current Behavior
Just out of curiosity
馃攧 Reproducible Example
No response
鈿欙笍 Tai-e Arguments
馃攳 Click here to see Tai-e Options
{{The content of 'output/options.yml' file}}
馃攳 Click here to see Tai-e Analysis Plan
{{The content of 'output/tai-e-plan.yml' file}}
馃摐 Tai-e Log
馃攳 Click here to see Tai-e Log
{{The content of 'output/tai-e.log' file}}
鈩癸笍 Additional Information
No response
馃摑 Overall Description
API design
I currently noticed that
CallGraphprovides two different APIs with the same default implementation,CallGraph.getCalleesOfM()andCallGraph.getSuccsOf():Tai-e/src/main/java/pascal/taie/analysis/graph/callgraph/AbstractCallGraph.java
Lines 71 to 75 in 21118b5
Tai-e/src/main/java/pascal/taie/analysis/graph/callgraph/AbstractCallGraph.java
Lines 155 to 159 in 21118b5
The
getSuccsOfseems straightforward to me, but thegetCalleesOfMtakes me a while to realize its meaning.My question: Is this a deliberate design choice? What is the rationale behind this?
Mutable vs Immutable
The callgraphs seem to be mutable by design, i.e., by allowing adding nodes and edges to the callgraphs. This makes several callgraph related operations inefficient, such as querying the successors and predecessors of a node, where caching the results might be difficult.
However, many applications do not actually modify the callgraph (e.g., traversing the callgraphs when computing SCCs). Is there any chance that Tai-e will introduce
ImmutableCallGraphor something like that?馃幆 Expected Behavior
Just out of curiosity
馃悰 Current Behavior
Just out of curiosity
馃攧 Reproducible Example
No response
鈿欙笍 Tai-e Arguments
馃攳 Click here to see Tai-e Options
{{The content of 'output/options.yml' file}}馃攳 Click here to see Tai-e Analysis Plan
{{The content of 'output/tai-e-plan.yml' file}}馃摐 Tai-e Log
馃攳 Click here to see Tai-e Log
鈩癸笍 Additional Information
No response