Eike:
> I propose three different functions:
>
> - EUROCONVERT with three required and two optional parameters and Excel
> semantics for compatibility.
Okay, I'm easily sold on that. Does anyone object?
Unless there are objections, I will modify my version of EUROCONVERT as suggested.
> - CONVERT with Excel/Gnumeric semantics, OOo will translate its
> CONVERT_ADD into CONVERT.
Great!
> - CONVERT_UNIT as OOo's general purpose conversion function; may be
> mapped by other applications to EUROCONVERT as long as no other
> units/currencies are involved.
I'd prefer calling a general money-conversion function CONVERT_MONEY instead of CONVERT_UNIT, and limiting CONVERT_MONEY to money. "UNIT" is too generic, and makes you think of meters, etc. I think we want to separate the function that handles currency fluctuation (CONVERT_MONEY) from the ones that don't (CONVERT, EUROCONVERT). That way, if an implementation loads an expression that uses CONVERT_MONEY, it immediately knows it has the "load up a conversion table" problem... and if that function doesn't appear, then it knows it does NOT need to deal with it. Also, CONVERT_MONEY can signal that its result is a currency, just from the name. You can't do that if you have a truly generic CONVERT_UNIT function, so it's not clear to me that we really WANT such a generic function as CONVERT_UNIT implies.
Having EUROCONVERT as its own function will mean that centuries from now, when those units are a memory, the function can be quietly dropped.
I agree that CONVERT_MONEY should quietly call/implement EUROCONVERT if given appropriate units.
> > There are a few functions left to do. Anyone willing to pick up one of the last ones left?
>
> I'll first concentrate on a list of other TODOs I identified.
Great! I was primarily hoping for inputs from others who haven't defined a function recently.
--- David A. Wheeler
