Re: [Vala] Chaining up constructors.

[Yu Feng <rainwoodman gmail com>]

On Sun, 2008-11-23 at 20:24 +0100, Jürg Billeter wrote:
> On Sun, 2008-11-23 at 14:01 -0500, Yu Feng wrote:
> > On Sun, 2008-11-23 at 11:32 +0100, Jürg Billeter wrote:
> > > On Sun, 2008-11-23 at 05:07 -0500, Yu Feng wrote:
> > > > On Sun, 2008-11-23 at 11:00 +0100, Jürg Billeter wrote:
> > > > > You should use "private set" here instead of "construct" with the new
> > > > > construction scheme. This shouldn't cause any issues.
> > > >
> > > > The situation is:
> > > > (1) I need j to be a construct property because the object eventually is
> > > > going to be created with g_object_new.
> > >
> > > What's the reason that you use g_object_new to create the object?
>
> Any response to that?
Sorry; I forgot about it.

Because creating object via g_object_new is a required interface of any
GObject library. 

As an example, I remember some applications, eg, Mono(or pidgin, can't
remember exactly) was creating GtkWidgets from g_object_new instead of
the creation methods. It was several months ago though, donno if they've
changed to other fancy techniques or not. Gtk also provides a factory
method gtk_widget_new to do the same thing. 

I also remember reading from some tutorials(or learned from you?) that
_new in GObjects are merely convenient wrappers for g_object_new to save
you from a lot of typing. e.g gtk_menuitem_new_with_label. it creates a
GtkLabel, and call g_object_new with "label", the_created_label.




> > > Would it be possible to create the object with default values first and
> > > set the properties later?
> > Practically that works, but ...
> > After these properties(nodeName of a DOM.Node) are initialized by
> > g_object_new, they should never be modified. In the specification they
> > are stated as 'read-only'.
> >
> > If I modify them later, I have to make them writable. Besides gobject
> > doesn't have a built-in 'private set' property concept. Keep in mind
> > some language bindings can use g_object_set/set property to get and set
> > properties, therefore the paramspec for the property has to precisely
> > describe the property's behavior.
>
> 'private set' (and in the future also 'internal set') should not mark
> the property as writable in the paramspec, as the paramspec should
> represent the public interface, not the internal/private.

'internal set' maps to a static property _set function, that's fine. It
is also perfect to map the 'construct' property to an 'internal set' for
GType based fundamental classes.

Nevertheless 'internal set' should not replace 'construct'.
G_PARAM_CONSTRUCT is awkward, but it is a part of the GObject API.

CreateMethod in GObject is really awkward and difficult to get
accustomed.

Usually, when we are creating a object instance, we expect to
(1) allocate the memory,
(2) calculate the properties with construction parameters,
(2) fill in the properties.

But for GObject, we do the follows:
(1) calculate the properties from construction parameters,
(2) g_object_new, 
    allocate the memory
    assign the calculated properties.
    invoke KLASS->constructor.

the process is totally reversed. (The reversal must be intentional.)

The code generated by VALA also left me an impression that vala is
attempting to resolve the conflict between the intuitive way and the
GObject way by introducing _construct along with _new. Is it the case?

- Yu
> Jürg