Questions about GObjectification in GnuCash

[Derek Atkins]

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

>> > When will be performed a code clean up? I mean:
>> > (a) delete the documentation in headers,
>>
>> Never.  We WANT the documentation in the headers!  Why would you
>> want to delete this documentation?
>>
>
> To help others to better understand the code; users must use a API
> documentation like DevHelp can show, but new developers for QOF can
> understand so quickly the QOF's internals if there's not TOO many
> notes and documentation in the code (I can talk about my experience).

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.

>> > Are there any plan to delete QOF's class registration (to use only GObject)
>>
>> I don't think that's possible because we need to be able to
>> enumerate all the QOF classes.  So we will always need some
>> QOF class registration.
>>
>
> May be I need to look at the code more deeply to understand, becouse
> at the moment I've found that this registration is only required for
> objects' QofParamenter registration and some functions like
> qof_object_foreach, but some of this features could be replaced by
> GObject's ones, but this is to know what are YOUR plan.

qof_object_foreach() is used in a number of places (e.g. the
XML backend code).  We need to maintain that functionality for
the forseeable future.

> SUGESTION: may be you can use:
>
> #define GNC_ID_ACCOUNT g_type_name (GNC_TYPE_ACCOUNT)

Maybe.

>> > What about QofParam, will be replased by GObject properties some time forward?
>>
>> Unlikely.  Possible, but unlikely.
>
> Could you expand your opinion, isn't clear why is it unlikely?, are
> there any  QofParam's feature not in GObject's properties?

Yeah, the ability to dynamically add them.  GObject Properties are
all hard-coded by the object, whereas QofParams allow you to add
parameters as you add new relationships.

>> > Could QofCollections be GObjects?
>>
>> I suppose.
>
> Well make it happend.

Send me the patch.

>> > Could QofBook be the operation handler for updates/insert/delete
>> > objects in its collections or database?
>>
>> I'm not sure I understand this question.  What do you mean by
>> "operation handler"?  We already have this, sort of, through
>> the Backend APIs, so updates, inserts, deletes, etc. all happen
>> through the Book using the Backend.
>
> If we made QofBook encapsulate all backend operations, maybe it could
> help some API users to use GC in more easy, and could help the
> following point...

I don't see any reason to do that.  Users of the GnuCash API have
all the storage hidden anyways, so I don't see any reason to
make this change anytime soon.

>> > Could QofBook and may be more objects in QOF/GNC, be a GInterface?
>> > This could allow to create diferent implementations for
>> > update/insert/delete objects using a different library other than QOF
>> > (If it's possible, a propose is needed)
>>
>> Maybe?  I could certainly see making a QofQueriable interface as
>> a way to make objects be queriable, and then the QofQuery would
>> take a QofQueriable instead of a QofInstance.
>
> Is possible to create a GInterface called QofQueriable and attach it
> to QofInstance, then when used in QofQuery you can cast to a
> QofQueriable object and use its functions interface, don't need to
> convert QofInstance to GInterface to do this.

Um, yes, I understand that.  Indeed, I said exactly that.  But I
dont see anything ELSE other than QofQueriable that deserves being
a GInterface.

-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