The target node information is not available in update operation

[mohayemin]

I have a use case where I need the information of the target nodes in the EditScript. However, only the target node text is passed to the Update objects. For example the code at code_diff/__init__.py:L200 is

if source_ast.type == target_ast.type and len(source_ast.children) == 0 and len(target_ast.children) == 0:
  # Both nodes are tokens of the same type 
  # Only an update is required
  return EditScript([Update(source_ast, target_ast.text)])

I suggest that the last line to be replaced with:

return EditScript([Update(source_ast, target_ast)])

[cedricrupb]

I am not a fan of referencing the target tree in the edit script. I would prefer if the edit script is only dependent on the tree for which it was computed for.

In addition, finding the subtree which is related to specific operation is not always possible (e.g. what is the related subtree for Move or Delete operations?)

If you are only interested in the update operation, you could compute the edit map (see code_diff/gumtree/init.py#L23 ). Whenever there are two nodes with different labels in the edit map, we would generate an update operation (+ some adjustments of the child nodes).

[dusan-lukic]

I ran in a similar issue. In my use case I wanted reference to target node in Insert operation, whereas the Insert op only tells me how to re-create the target node.

However, the desire for the reference to the node in target tree naturally arises whenever someone is using this library to diff non-ASTNode trees. Typical pattern there is converting source and target MyNode trees into ASTNode trees and building ASTNode -> MyNode map during the conversion. Then the hope is that one will be able to convert chawathe's edit script into MyEditScript, which works with MyNode trees, and one has a very powerful gumtree functionality for their own tree structures.

But as soon as one puts ASTNode (or some derivative of it) as a dictionary key, the ASTNode becames non-fungable from the perspective of the caller, and just recreating traget ASTNodes will not cut it.

So, I was thinking, a simple addition of Envelope/Letter payload to the ASTNode and edit script operations would enable such use cases. Caller would be responsible for creating token payload when creating ASTNodes, and it would be the responsibility of the package to propagate the token to the edit script whenever recreation of a node is needed, so that it can be recreated with the same token. Tokens do not participate in comparisons, distances, hashes and similar, they don't affect gumtree part at all, they are just propagated.

Would you be interested in that type of change?

P.S. This is not critical for my use case because my diffing requirements are simple enough to allow me to get away with completely ignoring chawathe step and use only edit map + my own very simple edit script builder, but I thought this might be a nice addition to the package to enable it to be utilized in a wider range of applications.