Re: GObjectClass->constructor revised, g_object_newv_with_data

["Gustavo J. A. M. Carneiro" <gjc inescporto pt>]

On Tue, 2005-07-05 at 12:29 -0400, muppet wrote:
> On Jul 5, 2005, at 7:57 AM, Tim Janik wrote:
> 
> > On Tue, 5 Jul 2005, Gustavo J. A. M. Carneiro wrote:
> >
> >> Currently [construction properties will] be set by the GObject  
> >> system at the wrong time, i.e. before the python proxy object is  
> >> attached to the GObject instance.
> >
> > i'd rather say, you are trying to setup your proxy at the wrong  
> > time, i.e. after _init() which is too late. if you properly setup  
> > your proxy in _init() construct properties will work fine out of  
> > the box.
> 
> For what it's worth, this is similar to the approach we took with  
> gtk2-perl.  The perl+C combination object is set up the first time  
> the GObject is marshaled to perl; if that happens to be in a  
> set_property override as part of g_object_new(), then so be it.  This  
> works the same way for all GObjects, regardless of whether they are  
> derived in perl code.

  I think we already talked about this.  If I remember correctly, in
Perl you always use the equivalent of Python's tp_new slot, which is
responsible for creating the proxy object from scratch.  In PyGTK, for
historical and  compatibility reasons, we use tp_init/__init__ instead.
When subclassing in python, users' should override __init__ and call the
parent class' __init__, which means that by the time GObject.__init__
gets called we already have a PyObject, and in this case we have to
avoid creating a new one.

> 
> 
> 
> >>  If we attach the proxy after g_object_newv returns then it is  
> >> already
> >> too late to handle construction properties in python space.
> >>
> >
> > no, this is case (1), i.e. you are creating a C Object and have  
> > nothing todo
> > with its construction properties, e.g. a GtkButton. so attaching  
> > the python
> > proxy to the fully constructed object is good enough.
> 
> An important thing to remember here is that the _init()s will all run  
> from the inside out *before* any set_property()s get called by  
> g_object_new().

  Yep, I realize now the importance of this property.  This way we can
avoid overriding constructor, but unfortunately we need to pass an extra
pointer into _init.  Either TLS or an extra parameter works, but TLS is
not very nice.  I get this feeling we may get into trouble using global
variables if creating one instance triggers creation of another instance
before the first one returns.

  But I guess we can use TLS if nothing better is available...

  Regards.

-- 
Gustavo J. A. M. Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>
The universe is always one step beyond logic.