Recursive TriMesh return

Here's a small recursive method I wiped up to gather all the TriMeshes of a node recursively and return it.



Just posting it in case it helps someone out (and maybe a double check ;))



    /**
     *  <code>getAllTriMeshes</code>
     *  Recursively obtains all the trimesh children from a given Node and returns
     *  them as an ArrayList
     *  @param model Node to search
     *  @param meshes (Optional) returned meshes, can be null
     *  @return ArrayList<TriMesh> filled with any found TriMeshes
     */
   
    public static ArrayList<TriMesh> getAllTriMeshes( Node model, ArrayList<TriMesh> meshes ) {
       
        if ( meshes == null ) {
            meshes = new ArrayList<TriMesh>(1);
        }
       
       
        for ( Spatial mesh : model.getChildren() ) {
           
            if ( mesh instanceof TriMesh ) {
                meshes.add( (TriMesh) mesh );
            } else {
                getAllTriMeshes( model, meshes );
            }
           
        }
       
        return meshes;
    }

This should go in the User Code section… Aside from that, it is OK, just a question, why would you need to return it and pass it as a parameter?

Its a performance thing, if you provide your own ArrayList, it woudln't need to be created inside the Method.

You see that often in jME Functions also.

Also for the recursion.



Although I have found that it geeks on larger models, so maybe it shouldn't go into user code just yet.

Core-Dump said:

Its a performance thing, if you provide your own ArrayList, it woudln't need to be created inside the Method.
You see that often in jME Functions also.


Right, I know, but you would them not need to return it... since the main reason is the recursion step.

How would it get passed back up through the stack after the recursion without a return?



It also allows using null as the Param; without a return how would they get the results, since using null means no pointer was created or saved.



I also realize that a global ArrayList could used but it seems much more elegant this way.

If when passing a null you would throw a null pointer exception, and you never initialize the array in the method, then you don't need to return it to still hold the information… All objects in Java are passed by reference, not by copy, meaning that whatever you add in that call, it is kept when that function returns, and the same applies for recursive functions.



In other words, this does the same:


    public static void getAllTriMeshes( Node model, ArrayList<TriMesh> meshes ) {
       
        if ( meshes == null ) {
            throw new NullPointerException();
        }
       
        for ( Spatial mesh : model.getChildren() ) {
           
            if ( mesh instanceof TriMesh ) {
                meshes.add( (TriMesh) mesh );
            } else {
                getAllTriMeshes( model, meshes );
            }
           
        }
    }

If when passing a null you would throw a null pointer exception,


Why throw error when you can handle it??

I'm not being a snot, but rather serious.  That was the way I was taught to program.

Well, I don't want to turn this into a flame-war about programming practices  :wink: so the last thing I will say about this, is that I have never really liked function calls that take an argument and return the same argument upon calling it, and on top of it, they modify it… it just seems you should either create the object in the method and return it, or let the user pass it, and then make a side effect inside the method, but not return it.



I know this is used for convenience to chain calls, and such, but I think it is poor design.

duenez said:

Well, I don't want to turn this into a flame-war about programming practices  ;)

Very good idea, IMHO :) yet you give a great hook line for one as your post's concluding words:
duenez said:

I think it is poor design.

Or, in other words: "I hereby invite the many thousands of experienced java developers who have used that technique to a massive flame thrower deathmatch!"  :-o
Probably just me being oversensitive again, but I think on virtually any other programming forum I've seen on the web this would have started a HUGE flamewar immediately. Shows once more what a nice and cozy place this is :)
Shows once more what a nice and cozy place this is



Yeah, I agree.  No need to start charring bodies, since everyone should be welcome to their opinion eh?
:D



Or, in other words: "I hereby invite the many thousands of experienced java developers who have used that technique to a massive flame thrower deathmatch!"

ROTF  XD

Maybe I am just spoiled by this community, but I expect to be able to give and receive any rational criticism… (I reserve the right to decide whether something is rational or not  ) Now, seriously, you can certainly disagree with me, and I would actually encourage it, since diversity is the source of all new ideas.  :smiley:

You are spoiled by this community.  :evil:



Actually, IMHO the friendliness on the forums is probably one of the top reasons jME is as successful as it is.  (It's a rare thing these days!)