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/
pgphRWzULU4NA.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
