2 new methods for Node.java

I added two methods to Node.java and I’m thinking they might be good to have to everyone.



The first is to detach all children fitting a certain name. There is already one where you can delete a named child, but it would only remove the first occurrence. I wanted the ability to remove all children of a given name.



The second searches for a node with a given name attached inside the node and return it.



Here’s the diff.



[java]

This patch file was generated by NetBeans IDE

It uses platform neutral UTF-8 encoding and n newlines.

— Base (BASE)

+++ Locally Modified (Based On LOCAL)

@@ -339,7 +339,7 @@

throw new NullPointerException();



for (int x = 0, max = children.size(); x < max; x++) {

  •        Spatial child =  children.get(x);<br />
    
  •        Spatial child = children.get(x);<br />
    

if (childName.equals(child.getName())) {

detachChildAt( x );

return x;

@@ -349,7 +349,26 @@

}



/**

  • * &lt;code&gt;detachChildrenNamed&lt;/code&gt; removes all named children from the node's list.<br />
    
  • * These children will no longer be maintained.<br />
    

*

  • * @param childrenName<br />
    
  • *            the children's name to remove.<br />
    
  • */<br />
    
  • public void detachChildrenNamed(String childName) {
  •    if (childName == null)<br />
    
  •        throw new NullPointerException();<br />
    

+

  •    for ( int i = children.size() - 1; i &gt;= 0; i-- ) {<br />
    
  •        Spatial child = children.get(i);<br />
    
  •        if (childName.equals(child.getName())) {<br />
    
  •            detachChildAt( i );<br />
    
  •        }<br />
    
  •    }<br />
    
  • }

    +
  • /**
  • *<br />
    
  • <code>detachChildAt</code> removes a child at a given index. That child
  • is returned for saving purposes.

    *

    @@ -445,6 +464,27 @@

    }



    /**
  • * &lt;code&gt;getChildNode&lt;/code&gt; returns the first child node found with exactly the<br />
    
  • * given name (case sensitive.)<br />
    
  • *<br />
    
  • * @param name<br />
    
  • *            the name of the child node to retrieve. If null, we'll return null.<br />
    
  • * @return the child node if found, or null.<br />
    
  • */<br />
    
  • public Node getChildNode(String name) {
  •    if (name == null)<br />
    
  •        return null;<br />
    

+

  •    for (int x = 0, cSize = getQuantity(); x &lt; cSize; x++) {<br />
    
  •        Spatial child = children.get(x);<br />
    
  •        if (child instanceof Node)<br />
    
  •            if (name.equals(child.getName()))<br />
    
  •                return (Node) child;<br />
    
  •    }<br />
    
  •    return null;<br />
    
  • }

    +
  • /**
  • determines if the provided Spatial is contained in the children list of
  • this node.
  • [/java]

The functionality of the latter method is already implemented in getChild() (even recursive) <and the former one is simply done by getChild(“name”).detachFromParent()… :slight_smile:

getChild will work if you don’t have a spatial or whatever attached that also has the same name.



For example, if you have a spatial named star and a node named star, you might get either depending on which has been attached first. In my method it only looks for nodes.



I agree with you on the second count, but since getChild(“name”) and getNamedChild(“name”) go through the whole children list, I thought it would be more efficient if the class itself provided a method to remove a batch of named children. That way we avoid using two loops, one in the program and one in Node.java.



Does it make sense?

We were talking about something like iterators for children once, apart from such an implementation I think bloating Node with methods like these makes no sense, you can extend Node to do that based on the current needs. You might not just want to add or remove nodes but do other things. Also I think it makes more sense for example in a game to keep a list of special nodes that you want to modify instead of searching them each time by name.

Alright then. I’ll extend node instead. :slight_smile: