[dirGames-L] Re: OOP Question

[Alex da Franca]

Am 01.11.2005 um 14:52 schrieb Marty Plumbo:

>
> It looks like the key (for my situation at least) is that if you  
> *don't* set a variable reference to a script instance, you needn't  
> worry about it.

yes, with the little caveat of "the result", which I already covered.
I always catch the result of a function myself. as long as the scope  
of the variable is the current handler, you needn't worry any longer  
anbout the scriptinstance.

> It will be deleted automatically after execution.  Any references  
> though, including in the actorlist, must *all* be set to VOID to  
> get the instance out of memory.

in case of the actorlist the object should add and remove itself  
(following the OOP guidelines: every object should care as much as  
possible for itself)

to add an object to the actorlist:

(the actorlist).deleteOne(me)
(the actorlist).add(me)


to remove it:

(the actorlist).deleteOne(me)


-----------


as soon as I use timeout objects in my scriptobjects (behaviors) I  
add a destroy handler to delete the timeout as a first step  
regardless what happens. (it can be very annoying, if your movie  
stops during authoring for whatever reason and your timeout objects  
persist and funny things happen on the next start)

on endSprite me
   mDestroy me
end

on mDestroy me
   if ilk(timeout("nameoftimeout")) = #timeout then timeout 
("nameoftimeout").forget()
end



>
> I'm curious then, can I have Director list all of the script  
> instances current "alive" in memory?  Whether referenced by a  
> variable or not?

If it could, it would mean, that it stores a reference to each  
object, thus preventing garbage collection.
It would be nice, indeed, but to my knowledge, there is no such  
functionality.
It doesn't fit into what I understand in good style of OOP, as each  
object should be as much independant as possible, there shouldn't be  
that kind of "manager" where all instances are stored in one place,  
but rather each object shouldn't be connected to any other object, if  
not necessary for its own proper functioning.
the same is true for you, the programmer, you should design your  
object as if it was completely alone. exist the time it needs to and  
no time longer and safe resources whereever possible. it shouldn't  
need to "look" at how many resources are left to decide how much  
resources it wastes itself, but work in the same optimized way,  
regardless if there are many resources left or whether it runs as a  
part of a huge complex application.

---------------------------

   |||
a¿ex