Great. Thank you for the insights. Before I got overwhelmed with work and other commitments last year, I was experimenting with a set of base classes that would replace the lower level qof infrastructure. As part of that, I was also looking at an alternative xml concept where xml provided some fundamental utilities, but each class such as book and transaction would use those to read and write themselves. This keeps the data structures contained in the class itself rather than xml needing to know about engine class data structures. That effort did not progress far enough to bring up for discussion here or do a development branch pr, however.
I’m comfortable with redesigning and rearchitecting, but I am planning to go cautiously with import/QIF as it sounds like a lot people use that and the format is not well defined. I don’t want to introduce new bugs. On Sun, Feb 4, 2024 at 6:50 PM John Ralls <jra...@ceridwen.us> wrote: > > > > 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
