Cool addChild trick! Why don’t people use the return of addChild?

I was doing some home work on the addChild method and found that it's has a return type of DisplayObject. At first I thought how strange that is since  most people would never think to use addChild as a way to get a return value.  And that's when I had an idea. Why not use the return of addChild?

A very common thing to do when you add a DisplayObject to the DisplayList is to also save that same DisplayObject in a Array so that you have fast access to that DisplayObject if you need to use removeChild or what have you.

so why not addChild and push in the same line?

Actionscript:
  1. var _mc:MovieClip = new MovieClip();
  2. var array:Array = new Array();
  3.  
  4. array.push(addChild(_mc)); // addChild with push
  5. trace(array);//outputs [object MovieClip]

I know this is really simple and not a huge deal, but since I have never seen any one else use addChild in such a way I thought it would be cool to see what every one else thinks.

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • LinkedIn
  • MySpace
  • Pownce
  • StumbleUpon
  • Technorati

16 Responses to “Cool addChild trick! Why don’t people use the return of addChild?”


  1. 1 Keith Peters

    I just came to a similar realization myself. Usually I grab a ref, add to display list then set some props.

    var s:Sprite = new Sprite();
    addChild(s);
    s.x = 100;

    why not:

    var s:Sprite = addChild(new Sprite);
    s.x = 100;

  2. 2 Josh Chernoff

    Nice one Keith, see that is something you don't see every day. Simple and fast.

  3. 3 Josh Chernoff

    I wonder if there is any performance to gain from this?

  4. 4 Darrin Massena

    Taken another step, how about:

    addChild(new Sprite).x = 100;

    Great as long as you only want to initialize one property of the sprite!

  5. 5 Josh Chernoff

    superclass and return

    override function addChild(child:DisplayObject):DisplayObject {
    return super.addChild(child);
    }

  6. 6 juliana

    i'm using this code, that works.

    var loader:Loader = new Loader();
    loader.load(new URLRequest("pic1.swf"));

    pic1_btn.addEventListener(MouseEvent.CLICK, showPage);

    function showPage(event:MouseEvent):void
    {
    addChild(loader);
    }
    but when i try to put another btn and load another swf doesn t work.

    Does Anyone know how to load more then one swf files?

    thanks

  7. 7 Josh Chernoff

    Your kinda off "way" out in left field with that one there juliana.
    This topic was about how to use the return type of addChild and other methods that you would likely not think to use.

    But I'll be a good sport and give you a hint. Your problem most likely stems from your use of the loader class.

    You might consider posting such questions in the forums you will get better help there.

  8. 8 juliana

    i'm sorry!! i've been trying to find a forum and i couldn t find.

    Thanks anyway.
    :o)

  9. 9 Josh Chernoff

    np:

    our forum is new so not much people in there "yet" but still feel free to post.

    http://as3apex.com/forums

    also there is
    http://actionscript.org
    http://kirupa.com
    http://flashkit.com

    any one of them should be more then helpful.

  10. 10 MLohrman

    Is there any benefit to this besides slightly leaner code?

  11. 11 Martha

    Nice!

    I thought I was all alone. I've been routinely gathering all my children generated in loops into an easy to grab array like this:

    addChild(art);
    artList.push(art);

    I like your system -- short and to the point.

  12. 12 radekg

    What is the point of storing child items in separate array apart of making GC confused? If child items are in its parent why to access them with separate array?

  13. 13 Josh Chernoff

    well here is a small example.

    var someArray:Array = new Array();
    function someFunction():void{
    //make a bunch of sprites
    var sprite:Sprite = new Sprite();
    someArray.push(addChild(sprite));
    }
    //now what if I want to access the sprites?
    //Do I use the array or getChildAt()?

    removeChild(someArray[someIndex]);
    vs.
    removeChild(getChildByName("hadINamedItThisMightwork"));
    vs.
    removeChildAt(getChildAt(someIndex));
    //if I know the index of the child then this might work.

    get the point yet?

  14. 14 aestheticsData

    " var s:Sprite = addChild( new Sprite );
    s.x = 100; "

    it doesn't work. addChild returns a DisplayObject and not a Sprite. So to make it work :

    var s:Sprite = addChild( new Sprite ) as Sprite;

  15. 15 aestheticsData

    here is some performance test

    1st method:
    ----------
    for(var i:int = 0 ; i < NB ; i += 1) {
    var s:Sprite = addChild( new Sprite ) as Sprite;
    }

    2nd method:
    -----------
    for( var k:int = 0 ; k < NB ; k += 1) {

    var s2:Sprite = new Sprite;
    addChild( s2 );
    }

    average time:
    ---------------------------------------
    NB | 0.5K 1K 2K 4K 6K 8K 10K 12K
    2nd / 1st ratio | 1.3 1.6 2.1 2.7 5 9.3 9.4 9.4

    we can see that when there is fewer than 500 Sprite both methods are almost equivalent. But beyond 2K Sprites 1st method is a lot more shorther than 2nd. And around 8K and beyond the difference is big, but stable when NB increase over 8K

  16. 16 spender

    I know constructs like this:

    array.push(addChild(_mc))

    and this:

    var s:Sprite = addChild(new Sprite);
    s.x = 100;

    look cool, but unless there's a real speed benefit in a portion of code that needs optimization, I think it's better to keep things separated. Ultimately, the code is more readable this way which carries a far greater benefit than a snappy way of doing 2 things in a single line.

Leave a Reply