Add gio::FileEnumerator subclass #1740
Conversation
fbrouille
force-pushed
the
gio_file_enumerator_subclass
branch
from
22f05ae to
a6d1863
Compare
gio/src/subclass/file_enumerator.rs
Outdated
| .close_fn | ||
| .expect("No parent class implementation for \"close_fn\""); | ||
|
|
||
| // get the corresponding object instance without checking the reference count because the object might just be finalized. |
There was a problem hiding this comment.
close() is called during finalize()?! That means that this can't be provided as a normal virtual method then as it's unsound to access the full object during finalization (parts might already be freed, you can easily cause memory safety issues)
There was a problem hiding this comment.
I suggest to call close in dispose because in this case it is safe to access the object. See tests for an example.
I also added a comment in closet notify developers they have to implement dispose`.
There was a problem hiding this comment.
We can't depend on developers implementing dispose for safe usage though. Calling it in dispose seems fine but you'd have to make sure this happens automatically then.
There was a problem hiding this comment.
This could be done by adding a new method IsSubclassable::instance_dispose with default implementation which calls ObjectImpl::dispose.
Then implementation of IsSubclassable for FileEnumerator can overrides instance_dispose to call close.
Obviously extern "C" fn dispose must be modified to call IsSubclassable::instance_dispose instead of ObjectImpl::dispose
What do you think ?
There was a problem hiding this comment.
We can't depend on developers implementing dispose for safe usage though. Calling it in dispose seems fine but you'd have to make sure this happens automatically then.
We don't have a mechanism for injecting a call inside ObjectImpl's dispose. As currently for gtk4-rs composite templates, you have to call dispose_template in dispose yourself.
So I rather we don't block on this given the low usage of the API and just make sure it is clearly documented. We can revisit this once we have a clear mechanism for achieving that.
There was a problem hiding this comment.
Sounds good to me but also maybe in gio itself it should already call this in dispose instead of finalize.
There was a problem hiding this comment.
Can someone create an issue, also make it very clear in the docs here, and then we can get it in I guess
There was a problem hiding this comment.
There was a problem hiding this comment.
Can you also add a link to that to the docs here?
fbrouille
force-pushed
the
gio_file_enumerator_subclass
branch
2 times, most recently
from
9b3a128 to
07be086
Compare
fbrouille
force-pushed
the
gio_file_enumerator_subclass
branch
2 times, most recently
from
00ed370 to
8d61fbe
Compare
fbrouille
force-pushed
the
gio_file_enumerator_subclass
branch
2 times, most recently
from
d68a59c to
762cd61
Compare
…uccess or error Signed-off-by: fbrouille <[email protected]>
fbrouille
force-pushed
the
gio_file_enumerator_subclass
branch
from
762cd61 to
16d5609
Compare
Signed-off-by: fbrouille <[email protected]>
fbrouille
force-pushed
the
gio_file_enumerator_subclass
branch
from
16d5609 to
78c408c
Compare
3 participants
Allow custom implementation of gio::FileEnumerator