Questions about GObjectification in GnuCash

[Josh Sled]

"Daniel Espinosa" <esodan at gmail.com> writes:
> 2007/6/1, Derek Atkins <warlord at mit.edu>:
>> "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).

If you think the comments are too verbose, and could be more succinct or
concise, I think we would all love a patch that made things simpler.  I
believe the comments that exist now are way too wordy and have a low S/N
ratio.


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

(That sounds like a demand...)  It will happen when reasonable changes to do
so are committed.


>> > Could QofBook directy use a Database engine instead of in-memory
>> > collections? I mean: use database's tables, instead to have a
[...]
> 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...

Strictly API users shouldn't care about the backend.  You're not
suggesting API changes or simplifications.  As such, I'm not sure
why it would make it any easier or harder for API users.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo ${a}@${b}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20070610/800c92f3/attachment.bin