[Gnucash-changes] Fix function name.

Neil Williams linux at codehelp.co.uk
Thu Sep 15 16:50:10 EDT 2005


On Thursday 15 September 2005 9:11 pm, David Hampton wrote:
> OK, so its not the original literal name, but what its name should have
> been had Linas applied the same transformation he did to the parallel
> function.

(One of many.)

> I can set your mind as ease.  I just hauled down the gnotime CVS code
> and looked through it.  1) Gnotime isn't using the qof library from
> sourceforge but instead has its own local copy of the qof sources.

(GnoTime is packaged to use external QOF on at least some distributions - the 
internal QOF code is not maintained.)

> 2) 
> There's no reference in gnotime to the function whose name I changed.

That's a relief. Thank you.

> These aren't scan/print functions, but functions that produce various
> time_t values.  They are not gnucash specific but will be needed by any
> application that needs to deal with financial periods.

I don't follow. The only applications that deal with *financial* periods 
through QOF are GnuCash and CashUtil.

> By the way, despite what the comments say at the top of gnc-date.h,
> gnotime heavily uses the time printing functions from this file.

(That's why I didn't want to change anything gnotime used in 0.6 but leave 
gnc-date.c|h unchanged until I can start QOF v0.7)

> My mistake. I meant the cashutils frontend, not the qof backend.

OK. That part of cashutil is still incomplete, it currently outputs the date 
in QOF_UTC_DATE_FORMAT and the shorthand code isn't finished to use other 
formats. That will be a development of the pilotqof code that simplifies date 
range entry on a CLI by accepting 2005 as 01-01-05 to 31-12-05 and 2005-04 as 
01-04-05 to 30-04-05. (midnight in each case). The pilotqof code itself also 
needs to have a friendly display format.

> If 
> gnocash, gnotime, and cashutils are all converting UTC time values to
> the users local time, shouldn't they share functions.

I don't know it's worth sharing formats though, it may be just as well for 
each to use their own formats with one set of functions that call strftime. 
(CashUtil, naturally, will use those GnuCash formats that are appropriate - 
some may not work in a CLI context. I don't know yet.)

> If each needs to 
> be able to determine when the start of the previous fiscal year occurred
> (well gnotime doesn't) shouldn't they share code?

CashUtil and GnuCash - yes - but that could be part of the shared code that 
those two already need.

> I agree with the alert as far as the statement that the engine doesn't
> need any time conversion functions, time period calculation functions,
> etc.  The engine should only deal in UTC.

Agreed.

> That said, I believe all the 
> frontends will need these other functions and that they should be in a
> common file.

Maybe, but I'm not convinced time period calculations are needed outside 
GnuCash and CashUtil and they already share lots of code outside QOF.

> Today gnc-date.c is that file.

Those other functions you mentioned, (gnucash specific), adding those to 
gnc-date.c|h will only make things more messy. Is there another way? At least 
temporarily?

What if we plan the complete removal of gnc-date, splitting it into qofdate 
and cash-date? Alternatively, a temporary file that gets merged into gnc-date 
once the QOF functions are removed?

Third option, wrap the new functions in #ifdef (again) so that QOF can build 
without them. Get G2 out, then make sorting out gnc-date one of the 
priorities after G2 to allow QOF to be spun out.

> Clearly the fact the QOF  
> needs half the functions in gnc-date.c and doesn't need the other half
> is a problem.  It makes absolutely no sense to me to have the function
> gnc_timet_get_today_start() in gnc_date.c (where it lives today) while a
> similar new function gnc_timet_get_month_start() is forced to live
> elsewhere.

Agreed.

> Similar functions should be grouped together.  Whether that 
> means extracting the functions used by qof from gnc-date.c and putting
> them elsewhere, or extracting the non-qof functions and putting them
> elsewhere I don't know.

I don't mind taking QOF functions out of gnc-date.c|h into qofdate.c|h in due 
course - just not in v0.6

Eventually, I'd like all QOF files to use the same naming convention and there 
aren't that many gnc_ ones left but that's potentially quite awkward. 
Thereagain, the longer that situation continues, the more awkward it becomes.
:-(

Naturally, gnc_timet_get_today_start() could then take it's rightful place 
with gnc_timet_get_month_start() as part of the wider move.

> Clearly either is a problem because the 
> currently declared QOF API contains these functions that don't directly
> relate to the stated purpose of QOF.

OK. Let's deal with this in QOF v0.7.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050915/1b581fd9/attachment.bin


More information about the gnucash-devel mailing list