Ability to cleanly destroy LiveAPI’s callbacks ?

I initiated a post on the Cycling 74 forum.
It was about the fact that if you instantiate LiveAPI objects, setting up callbacks, through javascript, I had doubts about how those callbacks could be cleanly, I mean: with a REAL memory liberation, destroyed and garbage collected.

Indeed, javascript’s Max implementations provide all stuff from classic javascript.
It means the garbage collector is also totally working.

So, if I want to make a LiveAPI call (instantiation) from javascript, I can do that:

trackObject= new LiveAPI(this.patcher, “live_set tracks 5″);

This row call the object in the LOM and “put it” in trackObject variable, basically for further access.

I can also do that:

trackObject= new LiveAPI(this.patcher,track_callback,”live_set tracks 5″);
trackObject.name = trackObject.get(“name”) ;
trackObject.property = “name”;
function track_callback()
{
post(“The track 5 is named:” + this.name;
}

This piece of code instantiate an object and observe if something changes and react by doing something.
Here, if the name of the track 5 changes, the callback is executed and pops out the new name.

If trackObject is out of scope (I mean, NOONE calls/runs the part of the code where it has been declared), the javascript’s (precious) garbage collector destroy and free the part of the memory where there was this variable.
It works.
BUT the problem is on the LiveAPI (and Live) side.
How could I be sure the callback is totally collected ?

Especially, I have been surprised by using the same piece of code by creating a HUGE table of LiveAPI objects, using callbacks and other stuff.
The Memory was a bit … busy and even the CPU (callbacks were working)

So I decided to … basically as I used to do in javascript: to try:
- myArray.length = 0; (this totally weird tip works fine usually)
-  myArray = null; (no comment)

Nothing worked fine BECAUSE there were those callbacks still working or even sleepy zombified or ?!

So the question became: How to really free memory from this callbacks ?

Tom answered and give an important information in the thread I began there.

cb_private seems to be a property for all LiveAPI objects (I guess it is trivial for those which don’t have a callback)

So, inside the callback, Tom suggests to add

delete liveAPIObject.cb_private

Where liveAPIObject is the related object for which you need to free the memory addressed for the callback.

Let’s test that in case we need it.

I suppose C74′s dudes will answer soon, but it is a nice news/clue/tip to test.