base-typemaps.i and budgets

[Christian Stimming]

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
> type.

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
> type.

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.

Regards,

Christian