Quoting Neil Williams <[EMAIL PROTECTED]>:
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.
That's fine..
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?
No, I have no objection to the existence of a function and a macro
that complement each other.
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.
Works for me.
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
[EMAIL PROTECTED] PGP key available
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
