> On Feb 4, 2024, at 12:11 PM, Brian Rater <blrn...@gmail.com> wrote:
>
> I've been looking at the import code and documentation and I'm wondering
> what the overall plan and path is. It looks like there is a "generic"
> implementation in the top level directory which has utilities that are
> being converted to C++. I can see the importers making some calls into
> this. What is the plan and where are we at?
>
> In particular, what needs to happen with QIF, which is still written in
> guile?
>
> I'm asking because I'm looking for a task to work on. My particular
> passion is writing C++ classes to replace legacy code along with adding
> tests and documentation. I've been reading over the source code and
> following the development list for several months, but I've had limited
> bandwidth until recently to make contributions.
>
> I've been looking at converting Import/QIF to C++ because it is written in
> guile (higher priority than converting the C code in my opinion), is fairly
> self contained, and the only alternative guile conversion code is reports,
> which is way too large in scope for where I am. Converting QIF has
> drawbacks such as needing extensive testing, and having limited existing
> tests for regression testing, however.
>
> My current thought is to directly translate the existing algorithms and not
> use the generic import to minimize introducing bugs, but others have
> probably put more thought into how to handle this.
>
> So I'm looking for some direction either on what the end goal is and how to
> achieve it, or direction to leave QIF alone for now and work on some other
> area of the codebase (suggestions welcome).
>
Hi Brian,
Welcome to GnuCash.
Rewriting the QIF importer to C++ is a reasonable task if that's what motivates
you. It's not on the roadmap in more than the most generic "get rid of Guile"
sense, but it does seem like a good project to take on. It's as good a legacy
conversion project as any at this point. The rest are kind of blocked by the
XML->in-memory SQL DB so that we can lose QOFQuery and stop creating huge
linked lists of every object in the book. That's design-and-implement rather
than rewrite an existing design so maybe not something you'd be passionate
about.
IMO it would be better to rewrite the QIF parser and transaction creator into
C++ and then wire it in to the "generic" infrastructure so that it presents the
same user experience as other imports.
I'm not sure how well that fits with your passion either, but I'm also not
convinced that it makes sense to reimplement functional algorithms as OO
classes. I reimplemented the Scheme report options system into C++ a couple of
years ago and it turned out to be a largely start-from-scratch redesign.
Regards,
John Ralls
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
