Read this article from the Community MX newsletter that pointed it out. Really, really cool and informative. One man’s opinion, but damn he’s smart… really good at articulating and not going on tangent trees that aren’t clearly traceable back to your original point. Dig his writing.
Anyway, a few beef’s I had with the article, which I know he didn’t want, but too bad.
He espoused the benefit of programming languages that manage memory for you as being more productive and quantified them into 3 points. However, 2 and 3 I tend to disagree with from the angle of Flash… still in limbo about it’s applicability to Director, but even before I start my upcoming email to Flashcoders to get some more info on a theory, he’s my frustrations. He says in the 2nd sidebar:
“…2) Because you don’t have to spend any time writing code to free memory or tracking down memory leaks.
3) Because you don’t have to carefully coordinate the exit points from your functions to make sure things are cleaned up properly.”
#2 doesn’t apply to Flash, because yesterday I did just that. Return values from attachMovie, even if defined as a var, don’t die if they are objects. I thought their pointers did, but I was wrong. And, I know #3 is really for those who’ve come from a C background, but as far as I’m concerned, it’s much like #2.
At any rate, I’m slowly changing my development methodology in Flash about utilizing return values from attachMovie/createClassObject methods. They return a reference to the component/movie clip created. I was using this for ease of typing, and flexible code, but now that I realize that I have very little control (still researching how much), and nothing short of nulling the reference at the end of the function, even though it is a local variable that’s supposed to die anyway, the mere fact that it doesn’t is just frightening. Not only that, but since AS2, it should be a class member anyway. Can you stop a web service connector created in this way? Nope. You need to clearly write out the web service’s movie clip path to remove the responder object, which you also need to keep around as a member variable to remove via removeEventListener.
Semantics aside, delete (ref_mc) not working, but ref_mc = null deleting a local variable is just… wrong. Maybe not technically, but in providing an application for me to develop in with an easy way to be irresponsible; it’s just asking for trouble. This is compounded by the fact that no one can clearly document Flash’s activation object, but they know all about how to hack it to keep scope when defining anonymous function’s on objects.
The point is, yes, I think it does increase productivity, but only if done right AND in a way that leaves little room for one to be irresponsible.
He also made 6 points on what is wrong with application development on the web. I though #6 was kind of cool because Central aims to fix that one.
“…6) Let people continue working when they are not connected to the Internet.”
Anyway, good article, definately worth a read over coffee.
Seems to me that many problems here are caused by chunking an “all new!” as2 engine on top of an as1 engine. This and short dev times pressures at MM probably cause these frustrating issues. Very MS-like if you ask me.
Maybe you could explain the whole “assign attachMovie return to a var even though it’s used in the function call” concept?
Sure.
var ref_mc = attachMovie(“SomeSymbol”, “cowabunga_mc”, 0);
ref_mc._x = 0;
ref_mc._y = 3;
ref_mc._alpha = 50;
In MX, I thought that was the shizz-nanny. That way, if I ever decided to change the name of “cowabunga_mc”, I only needed to change my code in one place, and was very easy to debug a broken component; if ref_mc was null, I knew the attachMovie was failing.
However, ref_mc doesn’t die it seems, like if you put an onEnterFrame on it.
ref_mc.onEnterFrame = function()
{
trace(“Yo, I’m: ” + this._name);
};
Notice ref_mc has a var in front of it. If done in a function, ref_mc is now local, and will die at the end of the function. However, since ref_mc is an object that outlasts the function, it becomes a pointer to the object. And, since the activation object somehow keeps it alive, it doesn’t die. You can do delete(ref_mc), and the delete will return false. You can, however, do ref_mc = null at the end of the function, and that will work.
Interestingly, you can put the trace(ref_mc) inside the onEnterFrame, and the activation object will keep it alive. However, it doesn’t trace out in the Debug > List Variables nor List Objects.
The C guys I work with say it makes sense. I however don’t like not knowing why the hell the variable is persisting, but I can’t see it. In Director, you could see how many references were pointing to an object. When all were gone, so was the object. In Flash, there doesn’t seem to be a way to do this, nor know where the hell the activation is living. It’s frightening, I guess, not having this control, and using this method for so long, but not knowledgeable of the potential memory pitfalls I “might” be getting myself into. The lack of knowing for sure is what sucks, is all.
Another thing I meant to mention, too, is if you don’t preclude it with var, remove the movie clip, the reference is now broken, but still there. You can see it output in the Output:
Level #0:
Variable _level0.$version = “WIN 7,0,14,0”
Variable _level0.ref_mc = [movieclip:]
Hey bro,
From Docs: “Predefined objects and properties, and variables declared with var, may not be deleted.”
So the question for me then is do local variables really ever get deleted seeing you can still access them from within the closure or is this an exception to the rule?
In regards to onEnterFrame, because ref_mc is a reference, when you define onEnterFrame you’re defining it on the object you’re referencing and not on the ref_mc variable.
-erik
Ah, but the question is the docs when? They are updated all the time and one has no clue what was updated… however, thanks for the … update?
True about assigning the onEnterFrame, I’m using it as an example on how to use the activation object.
Okay back to newbie: So we shouldn’t declare clips that have been placed on the stage by hand?
Yeah, you should declare them, but if you want to remove them, ensure your using destroyObject to so… or just use mc.swapDepths(0), and then mc.removeMovieClip().
Jesse,
What you are talking about has nothing to do with the reference returned from attachMovie. It’s just the old dirty activation object rearing it’s ugly head. Check this…
anyObject = {};
function setIt() {
var msg = “see you in hell muthafucka!”;
var args = arguments;
anyObject.showActivationObject = function() {
trace(“msg: “+msg);
trace(“args: “+args);
}
}
setIt(1,2,3,4);
anyObject.showActivationObject();
Any time you set a function on an object while inside of another function, all of the vars from the first function will persist in memory, supposedly until all references to that function are gone. Here’s another one…
function setter() {
var msg = “see you in hell muthafucka!”;
getter = function() {
trace(msg);
}
}
setter();
getter();
Geez, that one sentence really sums it up; about the function pointers. Good to know, thanks for the clarification!
errr..the term “activation object” is a new one on me…can someone explain that a little more?
A few sites have picked it up, but it’s a way to retain scope by utilizing it. I, however, don’t like the usage. At any rate, here are some reference links:
http://www.flex-mx.com/archives/000837.html
http://www.gskinner.com/blog/archives/000069.html
http://www.markme.com/mesh/archives/004286.cfm
Movieclips are different datatypes that everything else you create. Once a memory slot is slated for a mc it persists the entire life of the movie, if memory serves. There used to be a memory leak when you tried to call removeMovieClip as well. it was better at the time just to turn the mc invisible and rereference the slot when needed, somewhat like doing an available database for assets. You reused slots based on need, and only created the max that u ever needed.