Is it Possible to Explicitly Destroy Objects in Xojo?

Xojo
1

This, and the ever present Buy Now/Upgrade Now are reasons I don’t like Xojo and avoid using it.

This being, I can’t explicitly destroy objects … I think.
I know I’m supposed to set objects to nil for potentially immediate destruction. However, after a while the applications slows and resources grow, and it doesn’t seem to take my object = nil suggestions seriously (debug prints assure me that I am setting to nil and removing from the dictionary).

There is only one area that creates and removes objects, intentionally, to avoid having multiple references that could be preventing destruction.

It’s not that important, it’s an app I built to better learn Xojo for a client project that’s now finished. But I can’t help it and I need to know, since this space seems more knowledgable in the finer details that can get lost in the support forum, aside from the staff responses others here have gotten that I want to avoid.

I have a global dictionary, and each entry is (reference, object). I use the reference to later act on the object, and destroy it by setting the dictionary entry to nil and then removing it from the dictionary.

Should I be doing anything else in plain Xojo to achieve this properly? If the object has it’s own objects, do I need to nil those also? Should I be doing something magical, or using arcane knowledge? Or do objects just take time to unload and I should test longer?

Please don’t tell me to just pick a new language, I’m already transitioning to C# for this. I have the Xojo app done and I don’t want to bother listing it in the mac app store if this is the way things are™ And the client app is long done so i don’t necessarily need it for practice anymore.

However, this eats at my soul. Is Xojo really like this?

2

If you are removing the entry from the dictionary I don’t think you would need to nil it first.

Any objects inside the main object should be destroyed automatically when the main object is destroyed.

My initial thought is that you may have a circular reference somewhere as that would prevent the objects from being destroyed.

Can you share any code?

2 Likes
3
  1. yes setting an object to NIL DOES destroy it provided …
  2. you haven’t created a reference cycle that would keep it alive regardless

if you drop your reference to an object that is still referenced by something else that you no longer have a reference TO then you have no way to kill it any more

for instance if I have

 Class A
     property classBRef as ClassB

     Sub Constructor()
            classBRef = new ClassB(self)
     end sub
 End Class

 Class B
     property classARef as ClassA

     Sub Constructor(classAObj as ClassA)
            classARef = classAObj
     end sub

 End Class

the two objects hold HARD references to each other when created

So code like

     dim c as new ClassA

     .... more intervening code

     c = nil

WILL NOT drop C since C holds a hard reference to another B and that hods a hard reference to the one you created
AND you now have leaked that because your last reference in YOUR CODE is NIL

These CAN be hard to track down

Weakrefs CAN make that less likely to happen since they do NOT get counted as part of the reference counting

Often when I find I have this sort of issue I will insert a break into the object destructor JUST to verify that the objects are getting destroyed as I expected
If I do not get to that break then I know I have an issue
Tracking down where that issue occurs can be tricky

4 Likes
4

string of frustration expletives

Your comment set me in the right direction!

I went through my code and looked for items referencing each other, but didn’t find anything obvious. I went through the constructors a few times, made breakfast for the kids, came back and realized in the objects constructor I’m creating two timers, and in their various handlers, referencing them, and another class, in a similar way to what you mentioned.

It makes sense after the fact. I made the code less spaghetti, and now I nil the timers on the top level object’s close. It works perfectly now.

Damn, I can’t blame Xojo for this one. :stuck_out_tongue:

1 Like
5

ah yeah and if you used AddHandler to add event handlers that can add hard references (I think they are hard references and part of reference counting. I have to admit I forget this one)

Weak Address of Is problematic though since you have NO way to test it to see IF the item that was referred to exists any more like you did with weak reference

:frowning:

EDIT : see
https://documentation.xojo.com/api/language/addressof.html#notes

Note that if the method is an instance method of a class, the returned delegate will also retain a reference to the class object. This can, in some cases, lead to circular references, causing memory leaks if they’re not explicitly broken up after use

1 Like
6

I swear to god I read that page.
At some point.

And maybe forgot what I read. :rofl:

1 Like
7

Its an easy thing to overlook

You have no idea how many of those kinds of issues I hunted down in the IDE code base :slight_smile:
And I know there were some I never fully resolved

8

Don’t forget to use RemoveHandler before you nil your timer objects otherwise you might still leak objects.

2 Likes
9

What irritated me most with Removehandler is that you had to specify the specific specific function to remove from the event … which made writing generic code a bit more complicated…

After all, an event can only have one handler assigned at a time, so why does one have to be more specific that just saying which event on the object?

Specifying which Event you wanted to remove the handler from should have been enough it seems to me!

  • Karen
1 Like
10

I don’t know why the guys were not using a destroy function for any object you want to destroy. With Java GC takes care (like with Xojo) if an Object dies like it should and is supposed to. If you want to destroy an object you can destroy it with simple

object.delete();
or with
object.finalize();

That would also be possible to implement for Xojo. Also there is in Java the autocloseable interface you can use with a simple .close.

I have no Idea why they did not implement such functionality. May be to avoid verbosity like java has? Nobody knows.

11

can you say “API2”?

12

Because they DONT use garbage collection like Java does

Its plain old reference counting
RefCount = 0 then destroy the object
But there are way users can make it so refcounts NEVER get to 0 (as I noted about) AND they have lost their own references to the objects

Now I’m sure someone will say “well if that happens and objects are leaked that way they should be cleaned up”
NO !
TBH I have done this DELIBERATELY for some things - like an app “heart beat” that is a singleton that just runs & refers to itself and then I abandon my reference

The heart beat goes on and one and I dont care if I dont have a reference
It might call back to the app instance via addhandler but I dont need the reference to it to make that work

Its JUST a different way to handle memory management than other runtimes use

13

nothing to do with API 2

This has been this way for 20+ years

14

NAA I can’t say that. It is deleted from my memory. Even after reading I can’t. AP what 2?

15

The problem is that this is not the best way to handle GC. But they should know what is best for them.

16

but the verbosity does

17

same solution as java and many other languages have
using statements

but many just avoided them
And so did, even with the Xojo framework,

    dim mb as new Xojo.Core.MutableMemoryblock

And complained about the verbosity

When they could have done

    using Xojo.Core // ONCE in the method etc
     
    dim mb as new MutableMemoryblock

but … :man_shrugging:
New tricks old dogs ?

18

Dave was talking about verbosity I think.

-Karen

1 Like