I was thinking the same thing. I'm pretty sure that when an app for Windows 
uses DotNET Framework, it takes some time to initially load the framework, then 
the app can launch. Once the app is quit, I do not think it unloads DotNET 
Framework, because the next time I launch the app, the process is almost 
instantaneous. 

If more than one app is using your "framework" (behavior script only stack) 
then it doesn't make sense to purge it. Now if you want to maintain a system of 
registering and unregistering your apps with your framework, and purging the 
framework when the last app quits, that would make sense. 

I find that a lot of times in lieu of an enhancement request, the problem can 
really be handled by a little ingenuity on the part of the end developer. As I 
have said in the past, Livecode is less like raw materials and a full set of 
tools (C variants or Java) and more like a constructor set. All the different 
parts have been made, and we really put the parts together to make something 
useful, like a toy house for example. The logical conclusion to any approach to 
less granularity than necessary would result in opening the box of the 
constructor set and finding inside walls and a roof. But what if I didn't want 
to make a house?? 

I guess I'm saying that it's more beneficial to keep as much flexibility in the 
hands of the developer as possible. It's up to us to detemine how best to put 
the parts together in a way that suits us. 

Bob S


> On Feb 10, 2017, at 09:48 , Richard Gaskin via use-livecode 
> <use-livecode@lists.runrev.com> wrote:
> 
> > __ 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.


_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Reply via email to