Open ash-aldujaili opened 5 years ago
They are more than the same extent, they are the same reference, see Type property in ConvertExpressionAst
and Attribute property in the base class AttributedExpressionAst
.
Maybe it looks a little weird, but I don't see any real problems.
Thanks for the prompt response.
I am using the tool to extract structural info from PS scripts from a graph-theoretic point of view. If they are the same reference, would it be safe to ignore the second node ( I am assuming that both point to the same object and its properties)?
In other words, An AST with two children of identical text (as provided in the tool) is---functionally---equivalent to another AST with one child of the same text?
Yes, I think it's safe to ignore a second immediate child with identical text.
Noted, with thanks. I wonder what the advantage of such a setting is for the parser!
There is a single field backing both properties, so it's simply a convenience api.
The derived property also adds a type cast which makes the convenience api even more useful when editing code - giving more appropriate completions.
I tried running the tool on the module itself as follows.
I found the following children nodes with the same texts (why is that? I assume nodes would have distinct IDs), see below; two instances of TypeConstraintAst nodes of exactly the same offsets.
Debugging these two nodes, I found the following:
In a nutshell, one $child has
TypeNameOfValue System.Management.Automation.Language.AttributeBaseAst
and the other hasTypeNameOfValue : System.Management.Automation.Language.TypeConstraintAst
, yet both map to the same textTypeConstraintAst [2918,2942)
.Any thoughts on the above?