[Gtk-sharp-list] widget destruction

Nicholas Frechette zeno490 at gmail.com
Tue Mar 8 10:20:24 EST 2011

Plenty of C#/.Net libraries offer a Dispose and a Destroy equivalent:
System.IO.Streams offer Dispose and Close as well as a lot of other
The main confusion right now is that Dispose and Destroy do different things
but for example, FileStream.Close calls FileStream.Dispose (Or is it
vice-versa? Does it matter?) such that after you close a stream with either
function, it throws DisposedObjectException (or whatever that exception is
named) if you try and use that object. Something similar could probably be
done with GTK# without too much hassle.

My main concern with the finalizers is that in their current behavior, they
"hide" things you forgot to explicitly destroy and thus forces them to
linger in memory for 2 GC runs (not a leak, just longer lived than it
should, which isn't the case if you explicitly Destroy/Dispose).
If the C# community uses explicit Dispose everywhere for native resources
and if the GTK community uses explicit Destroy everywhere, it makes sense
IMO to keep the current trends and use the finalizers as a debugging tool to
help enforce it as opposed to hiding bad usage of the library going against
both philosophies.


On Tue, Mar 8, 2011 at 12:29 AM, Mike Krüger <mkrueger at novell.com> wrote:

> Hi
> > This brings up again the debate: should GTK# change the API in the 3.x
> > release to make Dispose() methods call Destroy() now that Gtk+3 broke
> > API anyway?
> I vote for using the dispose pattern. GTK#3 should be integrated more in
> It should not provide dispose and destroy methods - that's just confusing.
> Regards
> Mike
> _______________________________________________
> Gtk-sharp-list maillist  -  Gtk-sharp-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/gtk-sharp-list/attachments/20110308/3314a4aa/attachment-0001.html 

More information about the Gtk-sharp-list mailing list