[QOF-devel] Outline of new qofevent support

[Neil Williams]

On Saturday 25 February 2006 9:07 pm, Derek Atkins wrote:
> Quoting Neil Williams <linux at codehelp.co.uk>:
> >> The generator and consumer of the QofEventId need to
> >> agree on what the object of the event is.
> >
> > Absolutely. This would almost certainly mean a different QofEventId for
> > each type of object used and expected. That can't be resolved by QOF, it
> > needs to be stated in the docs and left to the user to ensure it actually
> > happens that way.
>
> Well, maybe.   It would mean defining that a particular QofEventId when
> applied to a particular QofEntityId would (or would not) imply a particular
> type of argument in the callback.  Nothing says that QOF_EVENT_FOO when
> applied to QofTypeFoo implies an argument of X and when applied to a
> QofTypeBar
> implies an argument of Y.

So leave it open? Let the API user decide how to reconcile which argument goes 
with which event_id for which entity. I'll put that into the docs.

> Admittedly, it would be nice to standardize, but in the grand scheme of
> things it's just a contract between the event generator and the event
> consumer.

OK. In which case, QOF will not put limitations on that contract - it will be 
completely up to the generator and the consumer to deal with unexpected 
arguments, incompatible arguments, etc. This implies gpointer arguments.

> > Do you actually want a gpointer or would a QofEntity be a better choice?
>
> I don't know.  I think passing gpointer is more general..  However all
> the uses I have in mind only require a QofEntity (actually a QofInstance).

> > WithArg infers non-objects being passed (like a GHashTable or GList, an
> > arbitrary struct / iterator, some arbitrary const gchar* or other weird
> > bits of memory) - was this your intention or would this be a better,
> > clearer, name base?
>
> Actually, yes, this was my intention -- it's closer to the way g_signal
> works -- g_signal lets you pass any kind of arguments back to the caller.
> Indeed, you can even define signals with MULTIPLE callback arguments!
> So, leaving it as a gpointer leaves it a little closer to where we'll
> get to be eventually with qof2.

OK. 

> > Your use case certainly centres on an item that is more of an Object
> > than some
> > arbitrary argument.
> >
> > I prefer the idea of restricting it to objects - or more precisely, a
> > QofEntity.
>
> Why this restriction?

Because I always try to make new function names etc. intuitive and your 
examples (including the statement above about what you have in mind for this 
part of the API) all related to QofEntity or QofInstance. If, in practice, 
the *only* uses of these routines will be QofEntity or QofInstance, I'd 
prefer that the function made this obvious. If there are future situations 
that will require more than that, gpointer is better.

> > Do you need this for QOF 0.6.2 (which otherwise could be released
> > tomorrow) or
> > 0.6.3 which is a likely release in the first week of April (coinciding
> > possibly with 1.9.3)? (i.e. as this is something you've just recently
> > thought up, is the idea due to an immediate need, educated foresight or
> > wishlist?)
> >
> I have an immediate use for it..  I'd like to set up an event handler that
> gets called whenever we add a new transaction into a particular account..
> The idea is that I can attach this handler to the A/R account and whenever
> a new transaction appears (or changes) I can perform business-level
> processing on the transaction.  For example, I can tell whether the
> transaction is tied to an invoice/lot or not, and if not I can try to
> figure it out or maybe ask the user for help...
>
> So, yes, this is something I'd like to see in 0.6.2.

OK. gpointer, with_arg naming style, 0.6.2.

-- 

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/20060225/fb089228/attachment.bin