Because the number of nodes and number of sourcefiles is zero-based, in order to retrieve the correct nodes, we have to write this in client code:
DO i = 0 to ParseUnit:NumNodes - 1: END.
could we just say that NumNodes is zero-based, and by default decrement NumNodes by -1 in the parseunit so the client code becomes
DO i = 0 to ParseUnit:NumNodes: END.
I think that this would be less prone to mistakes:
If someone writes (both are examples of wrong code)
DO i = 1 to ParseUnit:NumNodes: END.
then we have an invalid node number
whereas if we reduced the NumNodes
DO i = 1 to ParseUnit:NumNodes: END.
would only miss node 0, not have any invalid nodes.
zero-based vs one-based
I haven't looked at the code yet, so maybe I'm speaking out my backside...
But wouldn't that break the meaning of numNodes? I would expect numNodes to be "the number of nodes".
Maybe what you want is to introduce a new property, such as lastNodeNum (which equals numNodes - 1).
all I'm trying to do is
all I'm trying to do is prevent the obvious mistake of
I understand, but if
I understand, but if numNodes is not the number of nodes, then I will be the one making mistakes!
I also understand ;) The
I also understand ;)
The code
is not intuitive : what is this doing ? Is it counting to the number of nodes, or 1 less than the number of nodes ?
The obvious answer would be to "do away" with node 0
makes much more sense.
What is node 0 ? Is it the "root" of the whole tree ? Is node 1 the first child of node 0 ?
I suppose all I'm trying to say is can we hide the existence of node 0 from the client programs ?
/me goes away to look.
"What is node 0 ? Is it the
"What is node 0 ? Is it the "root" of the whole tree ? Is node 1 the first child of node 0 ?"
Yes and yes. There is always a Program_root node as the top node in the tree.
The rest of the programming world counts from zero, and there's not much we can do to avoid the mismatch with Progress.
The "node number" is relatively arbitrary, it could count from zero or count from one, it doesn't matter too terribly much.
You could shift ParseUnit if you wanted, so that the top node is node number 1 rather than node number zero. That might be easier on ABL developers than forcing count-by-zero on them. Then, it would only be up to anybody working with a mix of Proparse both on Java and ABL (rare) to remember that the node numbers are shifted by one.
I don't think there's a
I don't think there's a problem here. If node 0 is the "root" node, couldn't we reduce the Numnodes property by 1 and ignore node 0 ?
So if a program had 5 nodes
0,1,2,3,4
the program itself has 4 nodes (1,2,3,4) and the program root node.
So, Numnodes becomes 4 (as far as the ABL programmer is concerned). You would know that there is 5 nodes (0 + the 4 other nodes)
The Program_root node is
The Program_root node is part of the tree structure, it has attributes, etc. If I remember correctly, the root scope is associated with it, it is a Block node with block properties... there may be more. If I want to iterate through all the nodes in a parse unit, I expect Program_root to be included.
If I want to work with an array or list of all nodes in the parse unit, then I would expect the list size to be parseUnit:numNodes.
I think that would be the
I think that would be the better solution. I'll have a look at what i would need to change in ParseUnit. Thanks.
Re: I think that would be the better solution
OK