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 examples. 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. Nicholas On Tue, Mar 8, 2011 at 12:29 AM, Mike Krüger <mkrue...@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 > NET IMHO. > It should not provide dispose and destroy methods - that's just confusing. > > Regards > Mike > _______________________________________________ > Gtk-sharp-list maillist - Gtk-sharp-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/gtk-sharp-list >
_______________________________________________ Gtk-sharp-list maillist - Gtk-sharp-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
