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.
