Object::InsertChild behavior and other object functionality

[craigsapp]

I notice (via segmentation faults), that Object::InsertChild() does not attach the inserted child to the parent automatically (via Object::SetParent()). It would be preferable if it did set the parent at the same time; otherwise, it would be more proper to have InsertChild be a protected class member rather than public. (I cannot think of a case where you would want to insert a child and not have it attached to that object as its parent).

Related to this, I want to insert a child in the first position of an object. I don't see a one-liner way of doing that. I currently have to get the first child with GetChild(0) and then use Object::InsertBefore(). But also a check to see that GetChild does not return NULL. Object::GetFirst() would work in a similar manner, but also is a three-step process to insert a child to the front of the list.

I am thinking that it would be good to add Object::AddChildFirst() or Object::AddChildFront() to allow inserting a new child before any other children (and if there are no children, it would also work to insert into the empty list. In other words, this would compliment Object::AddChild by inserting on the opposite side of the list (since AddChild adds to the end of the list).

---

For identifying if an object has a specific attribute with Object::HasAttribute(), that function seems to test if the object has the attribute and if it is set to specific content. How does that work with u32string data since the input attribute value is string (and I am presuming many or all attributes are stored as u32string)? And more importantly, how do I ask an object if it has an attribute with a specific name (if it exists but I do not care what the value is)? Or do all attributes technically always exist in objects (and what about invalid ones)?

Would that be equivalent to checking for an empty string value? It seems like adding Object::HasAttribute(std::string name) with only one parameter for the attribute name and not the value would be useful to clarify the case where you only want to know if the attribute exists and do not care what its value is.

---

Is Object::SetParent(NULL) equivalent to Object::DetachChild(index)? (other than which object is being called). In other words, does SetParent inform the parent that it is moving out? Looking at the code, for SetParent it seems that it will not be informed that the child is leaving. If the current parent is not NULL, is it not better to tell it to detach the child when SetParent is called? It seems dangerous to allow a new parent to be set without it being detached from the existing parent.

[craigsapp]

Another related question is how do I move the children of a <harm> to a <rend>? The function Object::MoveChildrenFrom() seems appropriate, but the documentation says that the two objects must be of the same type, so I presume I cannot use that function.

Otherwise I will probably use Object::Relenquish() and then finally Object::ClearRelinquishedChildren().

Looking at the description of Object::ClearChildren() it seems that a better name would be Object::DeleteChildren(). This would make the function name similar to Object::DeleteChild().

[craigsapp]

It seems that a better name for Object::GetFirst() would be Object::GetFirstChild(); and likewise Object::GetNext() would be better named as Object::GetNextChild().

And likewise Object::GetPrevious() would better be named Object::GetPreviousChild().

[rettinghaus]

Object::GetFirst() get the first descendant. Usually it is used with a class, e.g., Object::GetFirst(ACCID) which gets the first accid, even if it isn't a direct child.

[craigsapp]

Object::GetFirst() get the first descendant. Usually it is used with a class, e.g., Object::GetFirst(ACCID) which gets the first accid, even if it isn't a direct child.

Yes that is OK and good to know. In that case ACCID is an input parameter which allows searching deeper. When the input is void, then it will be guaranteed to be the first child of the element (since there must be a child element in order to have grandchildren, etc.).

Perhaps have Object::GetFirstChild() and also Object::GetFirstDescendant()? That distinction will help make the meaning of the functions clearer in the code.

So also Object::GetNextDescendant(), etc.

---

How does Object::GetFirst(non-null-parameter) traverse the tree? Does it start with the first child's descendants and then after than go to the second child and its descendants?