Dirty entity identification.

David Hampton hampton-gnucash at rainbolthampton.net
Fri Jul 22 16:36:42 EDT 2005

On Fri, 2005-07-22 at 20:57 +0100, Neil Williams wrote:

> > I'm not saying you have to 
> > set the flag every time a change is made,
> ?? Then why the disagreement about passing the flag back from the collection 
> every time a change is made ??

You don't have to set the flag each time a change is made if the flag is
already properly set to reflect the state of the book.

> There is no need to set or check the book flag 
> every time a change is made. Can we agree on that?

No.  If the flag were labelled "other non-collection data in the book" I
would agree with you.  Its not.  The line book->inst.dirty reads as "is
this instance of a book dirty?"  If the name of the flag was something
like book->misc_stuff.inst.dirty then I could accept your

> > just that you ensure that the 
> > flag *always* reflects the state of the underlying collections.
> It does, absolutely it does - when called via the API.

That's bullshit.  The API correctly reflects the state of the book.  The
single *flag* book->inst.dirty does not.

> Honestly, this is driving me nuts because it's an argument about nothing. The 
> API has been fixed to work correctly and you're worried about the internal 
> workings behind that API? 

Yes.  QOF is still a part of the Gnucash source code so I worry about
the implementation, not just the API.  You are not the only person that
will have to read and understand that code.  Hidden assumptions like
this one (that book->inst.dirty doesn't have anything to do with the
state of the book, it only reflects that state of some subset of the
book) make code hard to read.   If QOF were an external library like gtk
I wouldn't feel responsible for it.

> Please just use the API, it's fine! Don't use the 
> flag directly, do use qof_book_not_saved and all will be well. Promise.

I have never once said that I want to use the flag directly.  I have
stated that the implementation should be different, and that the code is

> If it goes wrong, THEN you can complain - right now I'm happy, the API is fine 
> and I'm not going to argue this any further. 

Fine.  Commit your changes, I'll get back around to doing HIG work on
the G2 port, and we'll go from there.


More information about the gnucash-devel mailing list