Best practice for disposing of a wrapper and its wrapee

[maskedMan]

I'm working with AS3 and I'd like to know whether the approach to disposing of a wrapper and its wrapped DisplayObject would be frowned upon in polite (or impolite) society.

So, I'm looking at doing this in the wrapper itself:

public function dispose():void{

  _wrapped.removeEventListener(Event.FOO, onFoo, false);  // repeat as needed...

  _wrapped.stop();
  _wrapped.parent.removeChild(_wrapped);
  _wrapped = null;

}

Then after calling wrapper.dispose() I would assume it is safe to null the wrapper instance since I've not only dereferenced the wrapped object but removed it from its display list and nulled it out as well.

I guess my most pressing question would be 'Is it crazy to remove _wrapped from its display list from within the wrapper object?'

[rawmantick]

I don't think it's a good practice to pass the responsibility from parent to child. I think parent should control its children itself... children should know nothing of parent. They only should have their methods to be called from parent instance. If you wish the parent to be informed from within a child - let the child dispatch a "remove_me" event, parent listens to it and then removes the child that has dispatched the event. This way is more flexible...

[maskedMan]

Thanks for the perspective romantique.

I like your suggestion, but there are two things that concern me:

1. I'm concerned that using dispatchEvent(new ClipDisposeEvent(ClipDisposeEvent.DISPOSE)); might cause some sort of race condition where you have to hope that the event is handled by the parent. Yes, you've dispatched the event, but will the event be handled before the _wrapped object is set to null 100% of the time?

2. Since the _wrapped clip should have no knowledge of its parent, how then am I to assign the event listener to its parent? The parent must be a normal movieClip instance (no special subclass applied in the library). I really don't want the wrapper class to keep track of both the wrapped clip and its parent.



edit: Here's a thought. How about this...

public function dispose(wrappedClipParent:DisplayObjectContainer):void{
  wrappedClipParent.removeChild(_wrapped);
}

The object calling wrapper.dispose() does have a reference to the parent, after all. It still feels kind of odd though.

[rawmantick]

1. I'm concerned that using dispatchEvent(new ClipDisposeEvent(ClipDisposeEvent.DISPOSE)); might cause some sort of race condition where you have to hope that the event is handled by the parent. Yes, you've dispatched the event, but will the event be handled before the _wrapped object is set to null 100% of the time?

That's the point of a tree logic. Imagine a captain and a private. The private can ask the captain of something. But it's fully up to a captain if to listen to him or not. In fact you can make some "all-seeing" controller, that will have all the actor's references and will listen to their events and then execute corresponding commands. In fact why do you want to be sure that something will happen? For example when you use Loader class and is dispatches "complete" event. There is no sure someone will make something with the loader instance after it completes. It's up to you to set up a nesessary logic to make everything responsive in the way you need.

2. Since the _wrapped clip should have no knowledge of its parent, how then am I to assign the event listener to its parent? The parent must be a normal movieClip instance (no special subclass applied in the library). I really don't want the wrapper class to keep track of both the wrapped clip and its parent.

If no special class their is - then take a look at my forst one. Probably the all-seeing controller is what you need

// update:
like the system is a set of atomic items only knowing their own local things and only having their methods to call from outside and dispatching events to outside. The point of system is to have a structure of those atomic items, listen to their events and restructure everuthing correspondingly...

In fact, you all you need is not the big "able to do everything" system, but just to remove a child from withing its own code once - forget everything, and make what you've already made Don't warm you head too much about nothing

[maskedMan]

Haha, indeed all it needs to do is just work. It's still very early yet in the planning phases for how this project will work and I'm just trying to find ways to handle problems that are resistant to the ever-changing whims of clients and designers.

What I do know is that no matter what solution I settle on, I'll have to do cleanup eventually and if the wrapper can't dereference and dispose of its wrapped object properly then it doesn't matter how thoroughly the wrapper itself is dereferenced by its own parent, it still sticks around forever. There are going to be enough of these guys around that I can't afford to have that.