"Deleting" Stacks in Memory - What About Behaviors?

[Richard Gaskin]

Sannyasin Brahmanathaswami wrote:

 > When we delete a main stack, the main stack and all its substacks are
 > removed from memory.
 >
 > But if we delete a stack that has behaviors set from external
 > *_behavior.livecodescript  stacks for controls in the "main"
 > (parent?) stack, those behaviors are still in memory.
 >
 > Does it make sense to file an enhancement request, to at least allow
 > the dev to set a preference
 >
 > __ Delete behavior stacks from memory when stack using them are
 > deleted [YES/NO]

My vote: No.

Different stack, different purge.

I want to remain in control of when things get purged.

Imagine, for example, an app that uses multiple documents.  Once I've 
inited the stack containing behavior scripts, I'll want to allow the 
user to open and close any document stacks they like during the session. 
  If I lost control over then behaviors are purged, I'd have to add code 
to ensure the stack with the behaviors is properly set up each time a 
document is opened.

And as someone who does a lot of LiveCode training, I've come to 
appreciate that the fewer "sometimes" rules we have the better.

Right now we give the developer the freedom to manage their own stack 
purging (however wonky that syntax may currently be).

If we introduce a "sometimes" rule about if some other stack happens to 
have an object that had been used as a behavior, things get muddy quickly.



 > This is in line with trying to manage memory usage on small devices.
 >
 > Yes, someone will no doubt respond "but they are so small why are you
 > worried?"
 >
 > But small android phone with limited RAM, really do need help keeping
 > the heap as low as possible.  I am just looking for all possible
 > means to clear ram, then set a "policy" in app to do all possible
 > house keeping along the way: set images to empty, delete stacks not
 > in use are the main two "tricks" we need to have that are obvious;
 >
 > But that leaves libraries and behaviors that are not in use. So if we
 > *could* clean them up… why not do it.  Some times 200K means the diff
 > between running and crashing on these "weak" devices.
 >
 > Obviouslyl if one is using Libraries with Start Using, the intent is
 > probably that these are serving as globally accessible handlers. But
 > this is not the case with behaviors attached to controls in a stack
 > that may be deleted. So does it not make sense they are treated the
 > same way as sub-stacks when their "parent" stack is deleted?
 >
 > Before filing an enhancement request I want to check here with
 > everyone. What do you think?

If you want to purge things, purge them.

But please don't purge my things. :)

And given the relatively low overhead of all but the longest of scripts, 
I wonder how much of a difference it'll make in your app.

Could there be something with images or other RAM-heavy elements that 
may benefit from reviewing first?

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com