Re: GtkGC shared auto-release

[muppet <scott asofyet org>]

On Dec 22, 2007, at 12:20 PM, Torsten Schoenfeld wrote:

> On Sat, 2007-12-22 at 10:08 +1100, Kevin Ryde wrote:
>
> > > How about calling the package Gtk2::Ex::GCPool or similar?
> >
> > That could be ok.
> >
> > > That is, have Gtk2::Ex::GCPool->get bless the gc
> > > into Gtk2::Ex::GCPool::CustomGC and put the @ISA mangling and  
> > > DESTROY in
> > > that package.
> >
> > That'd make live easier for further subclassing would it?
>
> Hmm, I'm not sure anymore.  When I made the Gtk2::Ex::GCPool  
> suggestion,
> I was thinking that the thing that you call get() on and the thing  
> that
> is returned from get() are different conceptually.  But if you think  
> of
> get() as a constructor, that's not true.
>
> So my current thinking is that the most sensible name would be
> Gtk2::Ex::SharedGC.  Or maybe some name that conveys the automatic
> releasing done.  Gtk2::GC itself already offers shared GCs, so there
> ought to be something better than SharedGC.


This is rather interesting, as it's a corner of the API i don't recall  
ever visiting.

I get the impression that the ->release call is a bit of memory  
management magic that we have leaked by accident.  If you're going to  
release the GC for other code to use, you're going to lose your last  
reference to it (which is why it has to be done with DESTROY ---  
FINALIZE_INSTANCE won't be called until after DESTROY), so why should  
you have to call an explicit release?

Should we just add this DESTROY override to the bindings?  (Taking  
care to retain compatibility with code that calls ->release  
explicitly, of course.)

It seems silly to have such a small external sugar module to fix  
something like this...

--
The one difference between Dali and a crazy man is very simple: Dali  
is not crazy at all.
  -- Salvador Dali