Skip to content

Feedback on girepository 2.0: GIBoxedInfo's place in the type hierarchy

I think there is something not quite right about GIBoxedInfo, but I'm not sure what the solution is.

In g-i 1.0, there was a tag GI_INFO_TYPE_BOXED which according to the docs could be either a GIStructInfo or GIUnionInfo. But there were also separate tags GI_INFO_TYPE_STRUCT and GI_INFO_TYPE_UNION. (I believe that GJS always made the assumption that GI_INFO_TYPE_BOXED meant a struct, not a union and I'm not sure whether that was intentional or not.)

For example, we have this code that decides how to define a JS class from the GIBaseInfo that gets looked up.

In my experimental port to g-i 2.0, this code is choking on an invalid cast, because BoxedPrototype expects to be able to cast the GIBoxedInfo to a GIStructInfo and call GIStructInfo methods on it. (GIBoxedInfo doesn't have any methods, so there would be no way to read the boxed type's fields or discover whether it had any methods, anyway.)

Throwing a few possible remedies out there:

  • Officially make GIBoxedInfo inherit from GIStructInfo or vice versa?
  • Get rid of GIBoxedInfo and have a 'boxed' flag in the GIStructInfo and GIUnionInfo?
  • Separate GIBoxedStructInfo and GIBoxedUnionInfo types?
  • Keep separate, but give GIBoxedInfo its own methods?