The way I understand it, classes are loaded as global variables.  You 
can see them when you test the movie and click Debug-->List Variables.  
I was on a project with multiple developers. The Shell loaded many 
different swf files. Some of the developers used the same classes and 
slightly modified them for their needs. The issue was that the class 
paths were identical, but even though they were used in separate swf 
files Flash would not replace the first loaded class with the new ones 
from the newly loaded swf files and cause the file to "break".  This 
only happens if the class path is the same.  Also, after using the app 
for a while you can check the "List Variables" again and see that Flash 
had amassed every class ever loaded.  I ended up writing a Class 
Cleaner class to delete the global class variables and it works.  It 
fixed the broken program files.  I don't completely understand the 
details of Flash's garbage collection, but this solved my problem.

I based my class after the idea that I found here:

http://www.helpqlodhelp.com/blog/archives/2003_04.html

----- Original Message -----
From: Tyler Wright <[EMAIL PROTECTED]>
Date: Thursday, May 4, 2006 9:36 am
Subject: Re: [Flashcoders] destructors...
To: Flashcoders mailing list <flashcoders@chattyfig.figleaf.com>

> Ian's right.
> 
> ActionScript is a dynamic language with its own garbage 
> collection, for
> better or for worse. If you try to apply all the same practices and
> rulesfrom strict-typed languages that requre manual memory management
> you'll go
> crazy. The best thing to do is to realize this type of languages 
> strengthsand weaknesses and try to build on them. It's really up 
> to the ActionScript
> Virtual Machine now to do ALL memory management, along with your good
> practices of making variables local when they can be local and 
> dereferencingthem when you're done using them.
> 
> delete myObject;
> 
> by itself does not actually destroy myObject. Rather it 
> dereferences the
> variable name 'myObject' from the actual data. Later garabage 
> collectionwill take care of it if 'myObject' was the last 
> reference to the data. Doing
> a delete in this way on a local variable doesn't actually do 
> anything, as
> all local variables should clean on their own once their code block
> finishes.
> 
> Tyler
> 
> On 5/3/06, Ian Thomas <[EMAIL PROTECTED]> wrote:
> >
> > Um - I'm not sure it is beside the point. :-) Given that you are at
> > the mercy of the garbage collector, implementing a function like:
> >
> > class MyClass
> > {
> >   function cleanup()
> >   {
> >     delete _someProp;
> >     delete _someOtherProp;
> >   }
> > }
> >
> > is pointless anyway, because if you delete an object of MyClass (or
> > rather _mark_ it for deletion by calling delete() - that's all
> > delete() does, and only then if there are no other references to the
> > class) then its properties are automatically marked for deletion.
> > Again, unless there are any other references.
> >
> > The only time I've had to worry about destructors in a
> > garbage-collected language (such as Flash) is when dealing with
> > connections to resources - for example, connections to 
> databases, or
> > closing open socket streams, or releasing handles to video memory
> > buffers, that sort of thing.
> >
> > Those sort of things should be pretty rare in Flash... which is 
> why I
> > asked what you're trying to achieve, because in most cases you can
> > find a way around it.
> >
> > If you are dealing with some sort of resource that you want to make
> > sure shuts down properly when no-one is referring to it, one 
> method is
> > to explicitly request/release access to the resource and implement
> > reference counting.
> >
> > For example, here's a singleton resource class:
> >
> > class MyResource
> > {
> >   private static var _refCount:Number=0;
> >   private static var _instance:MyResource;
> >
> >   public function MyResource()
> >   {
> >   }
> >
> >   public static function getResource():MyResource
> >   {
> >     if (_refCount==0)
> >     {
> >       _instance=new MyResource();
> >     }
> >     _refCount++;
> >     return _instance;
> >   }
> >
> >   public static function freeResource()
> >   {
> >     _refCount--;
> >     if (refCount==0)
> >     {
> >       _instance.doCleanup();
> >       _instance=null;  // You could do delete here if you really 
> wanted> to.
> >     }
> >   }
> > }
> >
> > and then access it like so:
> >
> > var res:MyResource=MyResource.getResource();
> >
> > and when you're done
> > MyResource.freeResource();
> >
> > But that's really long-winded, and breaks as soon as someone 
> does this:
> >
> > var res:MyResource=MyResource.getResource();
> > var res2:MyResource=res; // Took a copy
> > MyResource.freeResource();
> >
> > res2.doSomething() // Breaks, because doCleanup() will have been 
> called.>
> > This sort of thing used to crop up quite a lot in C++; which is why
> > smart pointers and the like were invented.
> >
> > I can't think of too many situations where you might need that 
> sort of
> > thing in Flash; which is why I asked what you were trying to
> > achieve...
> >
> > Ian
> >
> >
> > On 5/3/06, Andreas Rønning <[EMAIL PROTECTED]> wrote:
> > > Kind of besides the point really. The real point is, in my humble
> > > opinion, that it should be possible to do it without 
> myClass.cleanup();> > delete(myClass);
> > > It becomes double naughty if your class instance is in an array.
> > > It's just a question of keeping the amount of fluff down to a 
> minimum.> >
> > > This is not a critical problem. I am merely asking for people's
> > > methodologies in self destroying classes.
> > >
> > > - A
> > >
> > _______________________________________________
> > Flashcoders@chattyfig.figleaf.com
> > To change your subscription options or search the archive:
> > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> >
> > Brought to you by Fig Leaf Software
> > Premier Authorized Adobe Consulting and Training
> > http://www.figleaf.com
> > http://training.figleaf.com
> >
> _______________________________________________
> Flashcoders@chattyfig.figleaf.com
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> 
> Brought to you by Fig Leaf Software
> Premier Authorized Adobe Consulting and Training
> http://www.figleaf.com
> http://training.figleaf.com
>
_______________________________________________
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com

Reply via email to