(AUDIT?) Re: r14892 - gnucash/trunk - Add a new QOF_TYPE_NUMSTRING to add numeric sorts. (#150799).

[Christian Stimming]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Derek Atkins schrieb:
> Well, here's the problem.  QOF is designed for objects (core types are
> just "special" types of objects), and QOF defines object sort order on
> a per-type (per-object-class) basis.  This means EVERYTHING you need
> to know about how to sort on a particular parameter must be defined by
> the type-name!  (...)
> 
> Now...  We COULD go and add a "sort-by" override function to the QOF
> Class parameter definitions, but that would be an even larger invasive
> change because it would change the API to the QOF Class definition.

Okay. After your additional explanation I understand that either
solution required a large invasive change. In that case we should
probably just stick to the existing API and use your implementation

> 1) Add a new type, which keeps all the class definitions the same as
>    they are (except changing TRANS_NUM from QOF_TYPE_STRING to
>    QOF_TYPE_NUMSTRING).

which is just what you did in r14892, right? The other solution sounds
even more error-prone in terms of the number of places that need changes.

> 2) Add a new (optional) QofParam member of type QofSortFunc, modify
>    each and every place where we define QofParam (which is every
>    QofClass definition everywhere in GnuCash), and change the code to
>    prefer a QofParam QofSortFunc over the default type QofSortFunc.
> 
> I think both approaches are invasive.  The former is more "QOF API
> friendly", the latter is probably "better" in that you can let each
> parameter define its own sort function.

I guess if we had some more object-oriented syntax avaible, it would
have made some sense to define the TYPE_NUMSTRING as "a kind of"
TYPE_STRING, i.e. define NUMSTRING as a subtype (inherited class) of
STRING. But this is C and we have to stick with what we can write here.
So eventually I think your implementation is just fine and I would agree
to a back-port, too.

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRRkmamXAi+BfhivFAQJI7QP/Xl9XMkNYNb07sPXShHxltO5REVgYnf8q
shkAB4dEiSD2V1bf7nHbFrujxCPh8KqYNgN8tOxktRprswagH/LKQsiQMBzaPzEg
TMnDO1oOM1nEtmH5Yjha32PEWlpvMkBh6E0wqkFS3tKb1ehPT0MnVAMskzEvudv1
2hSXRiLit9s=
=a5Ew
-----END PGP SIGNATURE-----