Blog

What is the difference?

In practice, they do the same, but are used differently. removeMovieClip can be used as a global method or local method (removeMovieClip ( someMC ) or someMC.removeMovieClip() ). destroyObject can only be used inside of a class that inherits from UIObject somewhere on the inheritance chain and takes the string name of the movie clip, not a movie clip path (destroyObject ( “someMC” ) ).

Fundamentally, however, they are very different. removeMovieClip can only remove movie clips that are in positive depths, 0 included. Therefore, if you dragged a List component on the stage, removeMovieClip will not work on it unless you use the swapDepths command to bring the component to a positive depth (hopefully unoccupied) and then remove it. If the playhead leaves, however, the frame where the List component is, and then returns, the List too will re-appear.

destroyObject does this for you automatically. Additionally, since movie clips/components in classes use member variables, it takes the liberty in deleting the component’s name; not the variable itself mind you, but the name nonetheless.

Neither deal with pointers to the object you may have created elsewhere.

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.