Hi Stephen,

Thank you for your explanation. From what I understand is that you presume an _active_ destruction of object B (in my case, just a simple int) but that does not happen (at least not by me :)) in any 'stop' function.

I could picture Roxen destructing all public class variables for example, and I currently get the problem with a public int, but I've also had problems with private class variables (a mapping(string:string) in this case)

Coen

On 3/29/2010 15:45, Stephen R. van den Berg wrote: 
Coen Schalkwijk wrote:
  
Does this mean that Roxen can control the or
has its own garbage collector?
    
No.

  
Ok. Could you (or anyone else?) tell me more about this, so I can
take this into account?
    
Picture this:

class A {
  object B;
  class C { 
     f() {
      references B;
    }
   };
}

What is perfectly possible is that class A still exists, class C still
exists, but that object B is destroyed.

Then once you reference B from within A.C.f() you have a problem.
This has little to do with the garbage collector, but more with when what
variables are destroyed (explicitly) in stop() functions of e.g. class A.


--
Signature Met vriendelijke groet / With kind regards / mit besten Grüßen,
Coen Schalkwijk
Software Engineer

coen.schalkwijk@rtl.nl

coen@rtlinteractief.nl

+31 (0)35 671 8915