GDA: current status

[Chris Shoemaker]

On Sun, Dec 10, 2006 at 10:37:46AM -0500, Josh Sled wrote:
> On Sat, 2006-12-09 at 19:47 -0500, Chris Shoemaker wrote:
> > BTW, one difference between FreqSpec and Recurrence: FreqSpec can
> > actually represent an internally-linked tree-structure of nested
> > "composite" FreqSpecs.  I have no idea why.  It's a very inefficent
> > data structure, since only the "leaves" carry the data, and the
> > structure is meaningless.  The Recurrence API handles this with a
> > GList of Recurrences.  However, I believe it's an unused interface at
> > the moment.
> 
> The composite FreqSpecs are used to handle:
> 
> * semi-monthly ("paycheck")
>   * composite(monthly(15th), monthly(30th))
> 
> * weekly M-F
>   * composite(weekly(Monday), weekly(Tuesday), ... weekly(Friday))
> 
> * weekly (checkboxes for dow's)
>   * composite(weekly(selection[0]), ..., weekly(selection[n]))

I didn't mean to imply that composite FreqSpecs weren't used, just
that GLists of Recurrences weren't used.

> I wouldn't call the structure "inefficient"; they both are using a
> GList.  

For every "interior" node in the tree of FreqSpecs, the "composite"
type information is duplicated.  AFAICT, that's useless overhead
because an arbitrarily complex tree structure is semantically
equivalent to one composite FreqSpec with a GList of all the leaves.

> While Recurrence has seperate API for computing the next
> instance of a single Recurrence vs. a List<Recurrence>, the FreqSpec
> just treats them both with the same interface.  

Good point.  I'm open to adapting this, if necessary.

> As you mention, composite FreqSpecs can be arranged in a tree, as
> well, which is nice, though unused in GnuCash.

I really have no idea why it's "nice", since it doesn't apparently
mean anything.  OTOH, if there was a plan to implement "AND" nodes,
where occurrances happened only when all children had a concurrent
occurrance, I could see why a tree structure would be useful.
Personally, I think that's overkill, though.

-chris