Declaring arrays/(or other objects) on behaviors, is there a "right" way? Anwser = No

Edit: According to Ashley, c3 does not pool objects behind the scenes. Advances in garbage collection have made this practice not nearly as important as it was 10 years ago. c2 used a generic pool behind the scenes, and recycled objects, but in most cases this isn't a concern anymore. In specific cases, where 100s of objects are being created/destroyed, pooling them is worth it, though either addonsdk/js will have far superior results than doing so in the event sheet.

-----

Hey all, I'm wondering, when creating a behavior,

if I declare the following in the constructor for a behavior instance (instance.js):

this._state = [false, false, false, false, false, false, false, false];
			this._lastState = [false, false, false, false, false, false, false, false];
			this._enterTime = [0,0,0,0,0,0,0,0];
			this._exitTime = [0,0,0,0,0,0,0,0];

Wait, now I'm super confused because this may indeed apply to me. This would be in instance.js

I add properties like so:

constructor(behInst, properties)
{
	super(behInst);
			
	//This is what the example on github shows:
	//this._testProperty = 0;
			
	this._vx = 0;
	this._vy = 0;
	//etc...
}

get _someproperty() {
	return this._somecoolmath(42) + this.somethingelse + this.etc;
}
_somecoolmath(n) {
	return (n === 42? n : 0);
}

set vx(n) { map.get(this)._SetVx(n); }
get vx() { return map.get(this)._GetVx(); }
set vy(n) { map.get(this)._SetVy(n); }
get vy() { return map.get(this)._GetVy(); }
setVelocity(x,y) { map.get(this)._SetVelocity(x,y); }

Not at all! A memory leak in a managed language occurs when you have objects that can't be garbage collected.

I said I wanted to avoid excessive garbage collection. "Accumulation", is a bit misleading, because you have memory that is either garbage, or it isn't, and it is basically defined as garbage by the collector. If the garbage collector marks something as garbage, it will be collected and so can't accumulate. You can create garbage, which will be collected, but a memory leak happens when the programmer has somehow mismanaged memory so that it can't be collected.

Garbage collection (major/minor/whatever) takes time to operate, which is why I like to avoid it if I can. The more garbage you create, the more time it will take to collect. Long lived objects typically have a larger impact when removed, and there is an overhead per object that the garbage collector has to scan.

A memory leak is a logical problem, in which the programmer has created references to objects that are no longer needed, but the references still exist on an object that is needed. A simple example would be if a character stored a reference to every bullet they shot in a list... Perhaps they have an ability that when triggered causes every bullet in the air to explode... Then when the bullet hits something, and is "destroyed" the programmer forgot to delete the reference in the list. Basically, you now have objects no longer in use, but they can't be garbage collected because the program still has a reference.

In something like c++, a memory leak is way easier to accidentally create, because there is no garbage collector. C# is like js in that is has was to create leaks using action/delegates/lists/etc, where any function pointer can keep an object alive to which the function points, which in turn is keeping other objects alive, and so on.

Memory leaks is simply memory that can't be released, despite no longer being in use. In managed languages, it just means that memory can't be garbage collected, though the collector will still scan it for opportunities to collect it.