Questions about GObjectification in GnuCash

[Derek Atkins]

"Daniel Espinosa" <esodan at gmail.com> writes:

>> The comments are part of doxygen documentation.  The code gets run
>> through doxygen every night so you can peruse the documentation:
>> http://cvs.gnucash.org/docs/HEAD/   The comments are the documentation,
>> so you cannot remove them wholesale.  However, as Josh mentioned,
>> reworking the comments to be more succinct would be a good thing.
>>
>
> Apears that move to gtk-doc or gnome-doc isn't a consensus right?

Nope.  We're using doxygen and have no need or want to change.

[snip]
> "f we encapsulate all data access operations (insert, update, delete,
> query) and backend operations in a GncBook GInterface (consider the
> operations in QofInstance object, most of them could be moved to
> QofBook or GncBook), it can help to use a diferent "backends" engines.
>
> If possible you can have:
>
> GInterface -> GncBook
> With functions to insert/update/delete/query any GObject derived
> objects (QofInstances objects)
>
> This interface must be implemented by QofBook, who is using the QOF's
> QofBackend infrastructure, to ensure the actual functionality and XML
> file format access unmodified .
>
> But is possible to have a GdaBook object implementing GncBook
> interface, then you can use GDA's databases backends, and becouse GC's
> engine objects use GncBook interface to access the data, GC can use
> any QOF (default data access) or GDA transparently, even any other
> convenient backend engine"

I don't see how this helps users using the GnuCash Engine API,
e.g. xaccTransSetDate() or xaccAccountSetName().  Those are the
APIs that applications use.  I don't see how making this kind of
interface would help.

It would seem to me that all this does is add a lot of complexity for
zero (or perhaps a tiny little) gain in functionality.  Adding
abstraction for the sake of abstraction is bad, without a real need..
It's a solution in need of a problem, and I don't see the problem and
no problem (read: no REAL WORLD problem -- theoretical problems don't
count) has actually been presented.  Even I am guilty of that error
and I regret some of the abstractions I've created.  I would really
prefer not to add more unless there's a clear and definite real
benefit, and frankly I (and apparently none of the other devs) just
don't see it.

What I see is someone who thinks that "GDA is the way" and wants
everything to fit into "the GDA Way".  I'm afraid I don't agree with
that and I'd rather retain the current Backend structure which has
worked well for many many years.  The backend API is fully extensible,
even if the current DB Backend isn't.  But that's an implementation
issue that Phil is working to correct.

Thanks,

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available