Repository navigation
[Feature Request] Support for @destructor #383
Description
I have a use case for creating objects in AssemblyScript that would benefit from a callback being called when they are garbage collected or destroyed. Of course javascript doesn't actually have destructors, and you can't tell when an object is being collected. However, if I could keep track of which objects were deleted, I could use a callback to communicate with my module consumer to notify them an internal object was collected.
This is just a simple example, utilizing the decorator syntax:
declare function notify_collected(ref: vec_3): void;
class vec_3 {
x: f64;
y: f64;
z: f64;
@destructor
protected __some_func_name() {
notify_collected(this);
}
}I don't know if this idea is good, or worth pursuing, but I just wanted to share it somewhere constructive to get feedback. Thanks for all your hard work on this amazing project!
Reacted by Hermann Rolfes, Patrik Smělý, Erik O'Leary and Luki Yang
Activity
[-]Support for @destructor[/-][+][Feature Request] Support for @destructor[/+]dcodeIO commentedon Dec 19, 2018
Should be doable, yeah, and there are certainly use cases where it makes sense to communicate destruction of a managed object to the host.
willemneal commentedon Jun 12, 2019
There seems to be more general need for a this in the new runtime. For example, a class which holds references to unmanaged classes and uses the destructor method to manually free them.
jtenner commentedon Jul 9, 2019
Currently my use case is solved by using rtrace.
onionhammer commentedon Feb 23, 2020
I think this is still a great feature request, even if your specific use case is taken care of
jtenner commentedon Feb 23, 2020
I still have software that would benefit from a destructor. But I have ways of working around not having it.
jedisct1 commentedon May 7, 2020
Old issue, but still relevant :)
My use case for destructors is WASI APIs, or more generally any external API that obtains opaque handles, that eventually have to be closed.
The current workaround is to use unmanaged objects and expect applications to explicitly destroy them, but this is not super convenient.
dcodeIO commentedon May 7, 2020
Created a little experiment linked above that might help to inform future design.
willemneal commentedon May 7, 2020
@jedisct1 It might also be nice to have something like
within python when using external APIs so that they will be cleaned up.MaxGraey commentedon May 7, 2020
With finalizer will be possible simple block scoping:
dcodeIO commentedon May 27, 2020
Closing this issue as part of 2020 vacuum because destructors turned out to be not feasible very likely, but I opened a new issue tracking the road ahead.