Re: GIcon thoughts

[Tim Janik <timj imendio com>]

On Mon, 14 Jan 2008, Alexander Larsson wrote:

> On Mon, 2008-01-14 at 10:12 +0100, Tim Janik wrote:

> > > Of course, this is slightly harder, as GdkPixbuf is a public GObject
> > > where we can't use toggle references. We could however implement this
> > > with some help from the GdkPixbuf implementation. For instance, if we
> > > add a resurrect signal to GdkPixbuf and have the dispose()
> > > implementation emit this then the cache could connect to this and grab a
> > > ref (for some time) before finalization. (The dispose call must also
> > > detect that the object is ressurected and avoid chaining to dispose.)
> >
> > you're not free to skip chaining in dispose() implementations (just
> > like you aren't free to skip chaining in finalize() or anywhere else).
> > adding a reference count in dispose is enough to "resurrect" an object
> > though, so just do ref(self); in dispose() but don't forget to chain up.
> > this'll prevent finalization (finalize() is only called for objects with
> > ref_count==0).
>
> Why is that forbidden? You can resurrect things by grabbing a ref, yes,
> but if you then chain up it'll free things like user data, etc, which we
> don't want in the case of a cache.

because code can do stuff like:

this->foo = acquire_resource();
class->release_resource (this);

where foo, acquire_resource, release_resource can be arbitrary names
of course, e.g. dispose.
if you break the assumption that some_class_real_method() is always being
called when class->method() is being called (either directly or via
chaining), you'll break random code portions.
(ancestor classes need to be able to make *some* assumptions about an object
in order to be implemented, and method calls working correctly is one
very fundamental assumption.)

---
ciaoTJ