Dirty entity identification.

Chris Shoemaker c.shoemaker at cox.net
Fri Jul 22 10:07:38 EDT 2005

?!?  Are we talking about the same project?  Gnucash?

<major snip>

Let me try to focus on the heart of the disconnect.  The "offline
backend" was just one fictional example of a case where the knowledge
of financial relationships makes the difference between a reasonable
and unreasonable implementation.  The real issue here is your
insistence that gnucash's "engine" has no concept of financial objects
or their relationships.  Maybe there's a terminology mismatch here.
By "engine" I meant the code under src/engine/.

The lack of a relationship between Transaction and Account is not
evidence that there is no "tree" in the source code.  Transactions and
Accounts don't have any direct relationship because they're not
supposed to.  What sort of direct relationship would you expect them
to have?

You keep saying that the financial relationships can't be in engine,
because QOF doesn't know a Split from a Watermelon, can't be in the
backend because "what the engine doesn't know the backend cannot
understand", can't be in QOF because all the financial concepts have
been stripped out.  Instead, you say that the financial relationships
need to be in the OBJECTS.  What exactly does that mean?  (And don't
bother explaining OOP to me; I just finished teaching a course in
OOP.  I get it, trust me.)  

> The backend does not understand an Account. It has no concept of a Split. They 
> are all just objects. The backend cannot do a tree search, no tree exists. As 
> I showed in the previous message, the source code HAS no tree - it only 
> exists in the human mind, the UI and the docs.
> There is NO direct relationship between an Account and it's Transactions.
> None. Zip. No engine call can go from an Account to a Transaction, the source 
> code is simply not built to support that, neither does it need to.
> Accounts know about their Splits and Splits know about Transactions and 
> Accounts. Transactions know nothing of Accounts and Accounts know nothing 
> about Transactions.
> The engine knows NONE of this. All the engine cares is that there are three 
> objects and N parameters. What the engine doesn't know, the backend cannot 
> understand and the book cannot find.
> That is why QOF can be spun-out as a generic framework, it has had all the 
> financial objects, all the human concepts and all the specific relationships 
> stripped out. It treats every entity the same way, everything is equal, no 
> hierarchy exists of any kind.
> In some ways, I regret using the term book - it implies a structure with a 
> cover, a table of contents, an index, chapters and page numbers that simply 
> does not exist. In reality, it's closer to a tombola: lots of coloured balls 
> with numbers stamped on them, each one identical to all the others in all 
> other respects. Balls of the same colour are attached to each other 
> (collections) which is where the analogy breaks down.
> > Well, the functions in the engine know that an Account has a list of
> > splits.
> No, they do not. The engine code does not know anything called an Account or a 
> Split. All it knows is that one object contains a pointer to another object 
> using a parameter identified using a particular static string. Some 
> parameters are strings, or integers or booleans etc. Until v.recently, no 
> object contained a list of anything, as far as the engine was concerned - 
> there was no parameter that could express a list of other objects.
> At no point does the engine have any concept of a Split or an Account or any 
> other human concept. It's all just objects and parameters. That's it.

??? The "engine" you're talking about is not src/engine/.

> > > The tree is too specific - QOF is generic and does not get into the
> > > specific conceptual relationships.
> >
> > In your view, where exactly are those relationships best represented?
> 1. The UI display
> 2. The docs
> 3. The minds of the developer and the user.

I expected you to add 4. OBJECTS.

> There is no place for specific conceptual relationships in the engine, the 
> backend, the book or the session.

Um.  Those financial relationships are a pretty important part of a
financial app.  And they need to exist in *code*, in the data
structures (which they currently do, BTW), and preferably not in GUI
code.  If you want to call something an "engine" that has no concept
of financial relationships, fine.  There still needs to be "a library
of core inter-related financial data-structures and the operations
that manipulate them, using those relationships."  Currently, that's
src/engine/, but we can call it something else if there's a consensus.


> -- 
> Neil Williams
> =============
> http://www.data-freedom.org/
> http://www.nosoftwarepatents.com/
> http://www.linux.codehelp.co.uk/

> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

More information about the gnucash-devel mailing list