Re: Why GObject::constructor, not GObject::construct?

[Tim Janik <timj gtk org>]

On 9 Jan 2001, Sven Neumann wrote:

> Hi,
> 
> Owen Taylor <otaylor redhat com> writes:
> 
> > So, why don't we just have a ->construct() virtual function that
> > is called after g_type_create_instance() and the construct parameters
> > are set?
> 
> Yes, I have stumpled across that problem when porting our object
> deserialization code to glib-2.0. I found a working solution with
> the current API, but it is more than ugly.
> 
> > Also, don't we need a g_object_newv() that takes a list of name/value
> > pairs, since g_object_new()/g_object_new_valist() isn't language
> > bindable? Or are language bindings supposed to call
> > g_object_constructor() directly? (It seems a little painful to figure
> > out which arguments are construct parameters, etc.)
> 
> Yes, sorting out the construct_parameters is a pain in the ass, but
> I couldn't find a way to access the functionality in gobject with the
> current API. The API you propose (name/value pairs) would be very nice
> to have.

urm, you should really wait for _newv(), especially since (construct)
properties may be shadowed by a derived type, normal not-construct
properties need to be sorted out from construct properties for the
constructor, and not supplied construct properties have to be supplied
as default values.

> 
> Salut, Sven
> 

---
ciaoTJ