Re: [Vala] Chaining up constructors.

[Jürg Billeter <j bitron ch>]

Hi Yu,

On Fri, 2008-11-21 at 21:27 -0500, Yu Feng wrote:
> Situation
> ========
> We have 2 different constructors, the construction block(CB), and the
> construct function(CF).
>
> for GType based classes, CB doesn't work, chaining up CF works.
> for GObject based classes, CB works, chaining up CF doesn't.

Chaining up CF should work fine for GObject based classes as well in
principle. The point where it fails right now is when you want to call
the base CF of a class in a C library. However, we should be able to fix
this by appropriate additions to the bindings - we need that independent
of the implementation if we want to support chain-up.

> New Idea
> =======
>
> The basic idea is to move memory allocation to _new functions, and let
> _construct functions initialize the properties. It is then much easier
> to chain up the _construct functions without worrying about memory
> issues. The other idea is to manifestly invoke '_constructor' for GType
> based classes. 
>
> With these two changes, we can arrive the maxium symmetry between
> GObject classes and GType classes. It also permits one to freely switch
> the base type of any classes between GLib.Object and nothing without the
> need of modifying any code.

I see construct block as something GObject-specific, I don't see any use
case for emulating it for non-GObject classes. Switching the base type
is already possible if you don't use the construct block.

> For GObject based classes:
> -----------------------
> 1. for each CF, generate a _new function,
> Object _new(param1, param2, param3...) {
> int n_params;
> GParameter * params = _construct(&n_params, param1, ....);
> return g_object_newv(TYPE, n_params, params);
> }
>
> 2. for each CF, generate a _construct function,
> GParameter * _construct(&n_params, param1, param2, param3) {
>       translate all the logic in CF, if there is an assignment to a property
> with getter and setter, create the correspoding GParameter
>         chain up is also done here by merging the return value of the
> parent's _construct function.
> }

This limits CF to property assignments again, while one of the main
goals of changing the construction scheme was to allow arbitrary code in
CF.

Additionally, this also slows down object construction a lot due to the
use of construction parameters.

Maybe it's easier to discuss the changes if I understand your motivation
why you are not happy with the new construction scheme. Can you please
clearly list the problems you have? Or if you prefer, write down a small
example that doesn't work (well) with the new construction scheme and
compare it to your proposal.

Jürg