// storage
var a:Array = new Array()
// temp shape
var p:Shape = new Shape()

// reference for graphics
var g:Graphics = p.graphics
with(g)
{
lineStyle(1,0)
drawRect(0,0,10,10)
}

// one rect was been draw.. now just add it to the stage
stage.addChild(p)
// and the array
a[0] = p

// now create another rect
p = new Shape()
g = p.graphics
with(g){lineStyle(1,0); drawRect(20,20,10,10)}

// add it to stage, and storage
stage.addChild(p)
a[1] = p

///
then, a[0] = first rect;
a[1] = second rect
and i dont have a single reference var for each Shape

/////
here’s a cool example of mine with source, of cource
(Simple particles 2 (100k))
http://wonderfl.net/c/A4dj

var badies:Arrary = new Array()
badies.push ( addChild ( new Sprite() as Sprite ) )

To me this doesn’t look to bad and I like the idea of using the returned data at the time of inception instead of having flash lookup the data twice ( shortest route principle ).

Those tests above are quite expected in fact as there is a table lookup factor for method 2 and every loop there is 1 extra added to the table as well as a new resource being allocated.

( s = addChild(new Sprite()) as Sprite ).x = 100;

Looks ugly, so probably shouldn’t be used unless you’re *REALLY* dependant on every CPU cycle, but there might be a situation where the concept could be useful to someone.

var s:Sprite = Sprite( mainSprite.addChild(create(Class, {x:0, y:0, rotation:90})));

// Instantiate and Set Properties
function create(obj:Class, props:Object):*
{
var o:* = new obj();
for (var p:String in props){
o[p] = props[p];
}
return o;
}

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.

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

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;

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?

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.