Re: GObjectClass.dispose and bringing objects back to life



I would be somewhat tempted to listen to all the stuff you're saying
below. But then I looked at the code you maintain[1], and I realized
it doesn't do anything of that. So I'm inclined to think that what
you're talking about is more about an ideal world that you wish we all
aspired to, but is not in any way related to how people write code in
the real world.

Benjamin

1: http://git.gnome.org/browse/gnumeric/tree/gnumeric.doap


On Sun, Dec 4, 2011 at 3:15 PM, Morten Welinder <mortenw gnome org> wrote:
>> What we probably also should do is deprecate one of the two
>> virtual functions, so people use the same one to clean up everywhere.
>
> That would be a _really_ bad idea.
>
> _finalize gets rid of the last fragments of the object.  Since random
> code could have obtained refs to the object, the object designer
> can generally not control when this happens.
>
> _dispose has two functions: (1) break reference cycles by getting
> rid of as many objects as it can, and (2) getting rid of externally-
> visible parts of the object and subobjects it owns.
>
> (2) tells you why you can't merge the two methods.  Widgets,
> for example, really need to go away from the screen when you
> tell them, not whenever something else decides to release a ref.
> Objects that have open files really need to close them at dispose
> time, not next Wednesday.
>
> Gtk1 didn't have dispose in name, but it had the destroy method
> instead.  Same thing.
>
>> [...] we [...] know that trying to support objects functioning
>> after dispose is like trying to make your code handle
>> NULL returns
>
> I don't think we know that, not do I think it's true.
>
> Making _dispose work really comes down to following one
> simple rule: after _dispose, the object should be as well defined
> as it was after _init.  I.e., anything you free you set to NULL
> and you don't free anything that was allocated in _init[*].
>
> M.
>
>
> [*] Unless you allocate a new dummy object to put in its place.
> That wouldn't make much sense unless you have big trouble
> with circular references.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]