xaccAccountEqual ?

[Hendrik Boom]

On Sun, Jan 08, 2012 at 11:52:41AM -0800, John Ralls wrote:
> 
> On Jan 8, 2012, at 10:40 AM, Hendrik Boom wrote:
> 
> > On Sat, Jan 07, 2012 at 04:23:16PM -0500, Derek Atkins wrote:
> >> Hi,
> >> 
> >> On Sat, January 7, 2012 2:35 pm, Hendrik Boom wrote:
> >>> What's xaccAccountEqual for?  Is it actually something gnucash uses (I
> >>> can't imagine what for), or is it just there because guile wants the smob
> >>> to have a function that tests deep equality?
> >> 
> >> I don't understand the question.  It's there to test equality of two
> >> Account objects. The API is used in a dozen places throughout the code.
> > 
> > I can see testing two pointers to Account objects to see if they point 
> > to the same Account object.  But I thought, perhaps wrongly, that the 
> > engine would make sure that no account would ever have two 
> > different Account objects, presumably by some kind of test before 
> > creating the second Account object..  
> > 
> > I do find myself wondering how one could ever be in the situation where 
> > two accounts are Equal, with Equal subaccounts, and even Equal splits 
> > except by amazing coincidence.  And then why that coincidence should be 
> > worth testing for.  Evidently I'm misunderstanding something here. 
> 
> Not two accounts, two account objects -- both of which might have been loaded from the same data in storage, or might have been deep-copied. (There was a partially-completed book closing implementation that did that as the first step. We're slowly weeding out the remnants.) 
> 
> I thought you were working on learning to script Gnucash with Guile.

In part, yes.  But I'm really trying to learn to write an introduction 
for people who want to learn to script Gnucash with Guile.

> Why are you worrying about the internals? 

Because

(a) it's hard to know which things are internal and which aren't.  And 
everyone trying to write scripts is going to have to figure out what 
they really need to know.

(b) When I saw this, I started to wonder if I had completely 
misunderstood how gnucash works.

(c) It's impossible to write something well without knowing more than 
you're writing.  Even in fiction, it's a truism that if the author 
don't know what brand of cereal the main character eats for breakfast, 
there's a gaping hole in the story, even if that fact never really 
enters into it.

(d) Besides, I start wandering through the docs, and encounter things 
like this.

> (Yes, it's true that the scripting interface exposes too much -- *far* 
> too much -- of Gnucash's internals. That's partly laziness on the part 
> of those writing the wrapper code and partly a legacy of Gnucash 1.x 
> when it was written mostly in Guile.

There's lots more here than needed for report generation, true.  But I'm 
sure there are going to be other things the scripting interface is good 
for, for which we may need to expose those internals.  So I vote no 
change here, for now.

But when it gets documented properly, one of the things that's going to 
have to be decided is just which of the internals are going to be the 
official interface, which ought to be preserved during further 
development, and which of them, though useful in the moment, are *not* 
guaranteed to be there in the next revision.

-- hendrik