Macros that affect program flow.

[Neil Williams]

On Sunday 26 February 2006 4:36 pm, Derek Atkins wrote:
> The point of a macro is to simplify the process of programming.
> In particular, it's supposed to allow you to replace repetitive
> code.

In this case, the reduction in repetition reduces the simplicity of the code. 
I accept the docs need to make this clearer.

> Pretty much EVERY INSTANCE of gncFooBeginEdit() and gncFooCommitEdit()
> looks EXACTLY THE SAME! 

in gnucash, maybe. It does differ elsewhere.

> It seems really stupid to me to make every 
> object have to call functions, check the results, and then return
> itself when a central macro can do it for you.

I've certainly had situations where I had to use the functionality in the 
macro in a function that returned a value. That's why I created the function 
versions in the first place.

> IMHO this is a DOCUMENTATION problem, not a clarity-of-API issue.

OK.

> Changing the macro not to return would IMNSHO make the developers
> life more difficult.

True, but you've no problem with having a complimentary function to use when 
the macro cannot be used?

> In my particular case I would just write 
> YET ANOTHER MACRO to use in gnucash, so we don't have duplicated
> code in every single qof object we define.  So why not just leave
> that macro, which would get written anyways, in QOF?

I'll reinstate it and leave the function as an alternative.

-- 

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/20060226/b98ee484/attachment.bin