[Gnucash-changes] Fix function name.

[David Hampton]

On Thu, 2005-09-15 at 18:46 +0100, Neil Williams wrote:
> On Wednesday 14 September 2005 3:01 pm, David Hampton wrote:
> > On Wed, 2005-09-14 at 08:01 +0100, Neil Williams wrote:
> > > On Wednesday 14 September 2005 7:11 am, David Hampton wrote:
> > > > -const gchar *qof_date_format_get_format(QofDateFormat df)
> > > > +const gchar *qof_date_text_format_get_string(QofDateFormat df)
> > >
> > > Should we just be changing the API like that?? This isn't a static.
> > > http://qof.sourceforge.net/doxy/group__Date.html#ga22
> > > (QOF is now on pre-release and I'd rather not change the API just now.)
> > >
> > > :-(
> >
> > Given that I was restoring the function to its original name, I thought
> > it was appropriate.
> I can't find a record of the original name you quote.

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.

> Linas' change was:
> const gchar *getDateTextFormatString(DateFormat df)   const gchar 
> *qof_date_format_get_format(QofDateFormat df)

Linas changed:

  getDateFormatString     => qof_date_format_get_string
  getDateTextFormatString => qof_date_format_get_format

The latter name doesn't describe the function properly, and is also
misleading becasue it implies that the first function doesn't return a
format string.  Both functions return format strings.  The latter one
returns a string that displays month name in textual format instead of
in numerical format.  My change corrects what I consider to be a mistake
in the code.

> It would probably break GnoTime if I allowed your change into QOF.

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.  2)
There's no reference in gnotime to the function whose name I changed.

> > Got any suggestions?
> 
> For now, all I can suggest is that you declare them locally where they are 
> needed and if that results in a new file in src/gnome/ then that would become 
> a suitable place for the other scan/print functions - ready for me to 
> deprecate the QOF versions for v0.7.

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.

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.

> > If a file-io backend needs date handling, and the UI needs date
> > handling, shouldn't they share a common set of functions?
> 
> Because the backend should not use LOCALE time settings, backends need to use 
> UTC.

My mistake. I meant the cashutils frontend, not the qof backend.  If
gnocash, gnotime, and cashutils are all converting UTC time values to
the users local time, shouldn't they share functions.  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?

> No. As the alert mentions, (written before I started), it is clearly NOT 
> suitable.

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.  That said, I believe all the
frontends will need these other functions and that they should be in a
common file.  Today gnc-date.c is that file.  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.  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.  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.

David