You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When you create nodes with specifying an integer as the name of the node, finding a node like so @tree[node_name] results in the node at the index, not the node named as the integer. The test below fails:
Thanks for reporting the issue! The problem is that the TreeNode.[] is an overloaded method, which actually uses the integer argument to retrieve the nth child. In the scenario above, @n_root[1].name is actually returning the 2nd child or the root (since the access is zero based, as for arrays). The test will pass if you use:
assert_equal(@n_root[0].name, 1)
However, I do agree that this is confusing. I think adding a warning message during the node creation will be better. Also, an optional flag in the TreeNode[] method can enable the use case you are looking for.
Expect to see the documentation change (and the optional flag based feature) in R0.8.3.
When you create nodes with specifying an integer as the name of the node, finding a node like so @tree[node_name] results in the node at the index, not the node named as the integer. The test below fails:
Perhaps integers should be explicitly disallowed as node names?
The text was updated successfully, but these errors were encountered: