On Thu, 12 Aug 1999 10:13:41 CDT, the world broke into rejoicing as
[EMAIL PROTECTED] said:
> It's been rumoured that [EMAIL PROTECTED] said:
> > > > Creating a new split might look like this:
> > > >
> > > > (define (initialize-split) ;;; Returns a gnc-split-structure
> > > > (let ((ptr (gnc:split-create))
> > > > (splitstruct (build-mystruct-instance gnc-split-structure)))
> > > > (splitstruct 'put 'gncpointer ptr)
> > > > splitstruct))
> > >
> > > What's the advantage to this over just using:
> > >
> > > (gnc:malloc-split)
> > >
> > > as provided by g-wrap as a wrapper for xaccMallocSplit and then using
> > > the normal (or some new ones if we need them) g-wrapped split
> > > manipulators? And if the current manipulators are just too scheme
> > > unfriendly, then we can add some friendlier wrappers to
> > > src/scm/convenience-wrappers.scm (or wherever) as I'm doing for the
> > > user interaction stuff..
> >
> > The plan is to have that set up the split, and then I set up all
> > the other splits, and can populate them all in whatever order
> > is appropriate from the "turning-QIF-into-GnuCash" perspective.
>
> How does this answer the "why not just use (gnc:malloc-split)" question?
Basically, I'm at the point where I'm marshalling all the data together
to get [2000-odd] transactions ready to load in.
I want to allocate the splits, allocate the accounts, allocate the
transactions, in whatever order proves convenient, and then link
'em all together in one fell swoop.
Consider this a "really-sophisticated-Scheme-(let) statement."
Pretend I'm setting up *lots* of stuff in the "variable declaration
part" of a (let).
(let
((Set-up-lots-of-stuff))
(and now do something with it))
I'm setting up the structures with lots of data in 'em so that I
don't have to build up horrendously long functions; I can keep the
functions short and sweet and readable.
> > > >From my semi-careful reading, I think you've mostly understand the
> > > structure. Note that AFAIK there's no global list of transactions
> > > anywhere. They're just pointed to by all the relvant splits they
> > > contain.
> >
> > That's the impression I get from the way the data structure seems to
> > work, so I think we're reading this the same.
>
> Right, there is no global list of transactions. There didn't seem to be
> a need for this, and if there had been one, it might have lead to confusion .
..
It would have the effect of making there be Yet Another List To Maintain,
when there's not really value to it.
> > > Also, I can't recall if splits are unique. I thought they
> > > were, but I'm not sure. i.e. is there only one copy of a given split
> > > that each account (on both the sending and receiving end) point to, or
> > > is there one copy for each account...
> >
> > That makes sense, and I hope there's only just the one copy of each
> > split.
>
> Splits are unique. A single split can refernce a single account only.
> Thus, a transfer between two accounts by necessity consists of two splits.
> Those two splits are paired together as an 'atomic unit' by means of
> the transaction.
Agreement all around. A Good Thing.
> > The thing to "get" is that I only intend for this stuff to persist on
> > the Scheme side for long enough to populate all the
> > splits/transactions/accounts. The data can then get dropped.
>
> One thing to 'get' is that the engine API is supposed to allow the
> engine to be implemented on top of other persistants-store or network
> devices. e.g. it is theoretically possible to implement the engine
> on top of a db2 interface, or make it run over the net. If everything
> goes right, such a change should not impact the scheme code or the gui,
> but please do keep this in mind. (this is why the malloc-split question
> is important).
Fair enough. I'm certainly not trying to "penetrate the barrier" to
do awful things to the engine; just to understand it well enough to
know what I'm supposed to be legitimately able to do with it. I think
I'm there now.
--
Coming Soon to a Mainframe Near You! MICROS~1 Windows NT 6.0, complete with
VISUAL JCL...
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
----- %< -------------------------------------------- >% ------
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
