base-typemaps.i and budgets
christian at cstimming.de
Sat Jan 18 15:48:51 EST 2014
Am Donnerstag, 16. Januar 2014, 15:52:49 schrieb David Osguthorpe:
> This appears to be a problem in the swig out typemap in base-typemaps.i for
> GList type structures.
> This typemap is defined differently for python versus scheme - here Im
> specifically dealing with the Python version.
> The problem found returning budgets is that this matches any arbitrary GList
> whose type is not defined in the previous else if components of the if
> structure, hence a list of budgets is returned as a list of gnc_monetary
I think this is an error of the swig description. To me it sounds someone
added the mapping for the GList<gnc_monetary> (C++ notation) for whatever
reason, and that person didn't notice that this mapping ends up as a catch-all
for other functions that contain a GList in their definition.
> Question is why is this routine defined for various specific types
> eg CommodityList *, SplitList *, AccountList *, LotList *, PriceList *,
> EntryList * where it seems to me the elements must always be of a specific
I *thought* this is the desparate attempt to map the programmer's knowledge
that "a specific GList contains only commodity pointers" into the correctly
typed python container. This lack of templated container types is one of the
bigger bummers of our core API. Instead, every container is a "GList*" and if
we're lucky, it contains the type we are expecting :-)
> Also, returning a void type for untested element types would seem to me to
> be better than returning a wrong type for a generic GList (it may be
> possible to re-map the swig void type in python later).
Absolutely. If we don't know anything, we can only return a void type.
However, in almost all usages of GList throughout gnucash the actual value
type is known and hopefully at least mentioned in that function's
documentation ("a GList containing xy"). In C/glib, unfortunately that's about
all that is possible.
More information about the gnucash-devel