Re: [Vala] [PATCH 2/2] Map GIRepository "record" type to Class instead of Struct

[Calvin Walton <calvin walton gmail com>]

On Fri, Jul 30, 2010 at 04:42, Abderrahim Kitouni <a kitouni gmail com> wrote:
> Hi,
>                   في خ، 29-07-2010 عند 21:14 -0400 ، كتب Calvin Walton:
> > The GObject Introspection "record" type is actually a reference type,
> > unlike the pass-by-value semantics of the Vala Struct. Map the "record"
> > type to Vala's Class (with is_compact set), as that seems to be the
> > closest mapping.
> I don't quite agree with this one :
> * There is no difference in passing structs and compact classes except
> for out/ref arguments. (structs aren't passed by value in the GObject
> profile).
> * in some cases, both struct and
> * Some heuristcs can be used (e.g. if it doesn't have a constructor it's
> a struct) but they aren't always reliable.
> * G-I already has the caller-allocates for passing out arguments, which
> I believe is the right thing for this if it can move to the type
> definition rather than in some out argument.

Yeah, I wasn't particularly sure regarding this change. It fixed
compilation for me with one object in one .gir file, but it doesn't
seem like a perfect general fix. (It doesn't help that the
GIRepository library that I'm using right now has a large variety of
plain C structures, passed by reference or not, either with hidden
implementation or not... It doesn't quite fit into the GObject model.)

I'm not totally sure (I don't have the code with me right now), but I
think the particular problem I was having was that the C type was
incomplete, but because it was a Struct in vala, vala had attempted to
allocate one on the stack.

In this case, I might have been able to work around the issue by using
a pointer to the record and manually managing memory, I'll try that
later.

On the other hand, the basic type additions in my first patch are
pretty trivial :)

> So, in the end I'd rather file a bug on gobject-introspection for moving
> caller-allocates from the argument definition to the type definition and
> use that (that's likely to be painful since some bindings already use
> this, but remember the magic word "Vala", it can help ;-)).

Yeah. gobject-introspection seems to work fine if you have tidy
GObject interfaces, but it doesn't seem to be able to describe all the
subtle nuances of a C interface.

> As for Alias, you want it to be of the same type as the parent, but I
> can't find how to do it (how to find the type of the parent before the
> symbol resolver is run).

Hmm. It might make sense to delay parsing the aliases until after the
base type they reference is defined, but then you have to worry about
other objects or methods using the alias name in the mean time.
Perhaps some sort of out-of-order parsing is needed overall.

-- 
Calvin Walton