Robert Graham Merkel <[EMAIL PROTECTED]> writes:
> Can we put this discussion on hold somewhat until the rest of the
> developers get back from holiday? I think we've posed some concrete
> problems, which have led to some rather interesting suggestions
> improving the engine.. However, I believe some work has been going
> on in this area and I'm sure that Dave and Rob will have quite a bit
> to say on this.
Well, we had been planning, and I think Bill's been working on, adding
a frame/slot, key/value pair, hash-table, whatever you prefer to call
it to several of our basic data types. This is to be used to record
whatever meta-level information we need for a given object. In fact,
the plan is to have two hashes in each relevant data structure, one
reserved hash-table, for "official" use, and one for whatever the user
likes -- this second table would also act as an effective testing
ground for new systems that might eventually become "official". I
believe Bill's implementing these for Transactions, Splits, and
Accounts, and is using the glib hash tables. He's also writing the
code, which will be apocryphal as soon as I finish the text data
format, to read/write these structures. The data value for a given
key can be another hash, so the structure is recursive.
Once this is done, we'll have to have good documentation indicating
what different keys are being reserved for. For example, it seems
clear that, as Richard has suggested, that we need to record the links
between related accounts when handling a dividend. This can be done
with reserved key pairs like "dividend-from", etc.
Frankly, you could argue that we could just switch to the hash table
as our fundamental data structure, but I'd like to address that right
now. While it would be possible, it's probably worth while to keep
the more important fields, which will be accessed much more often and
are *always* needed, as actual fields in a struct. However, if we
make sure to always use setter/getter functions to manipulate these
fields, then we can change the internal representation to whatever we
like without external impact.
Does this seem to match OK with what everyone needs?
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
