On Thu, Sep 22, 2005 at 09:52:04PM -0400, Kohei Yoshida wrote: > > But speaking in the short-term, what would that affect us with those > existing Calc functions that share the same name as Excel but behave > differently? For instance, there exists the CONVERT function that > work differently from Excel's counterpart, but we use CONVERT_ADD for > compatibility reasons. I've known of several others that are just > like that, with a _ADD suffix.
Seems reasonable. In Gnumeric we used GNUMERIC_foo for gnumeric specific functions but we can easily debate the specifics of how to namespace things another time. > Another concern is, say, we have come up with a great and useful cell > function that would only exist in Calc but not in Excel. Would such a > new cell function be easily accepted, or rejected out of fear that it > would cause a compatibility headache with other spreadsheet programs > (or simply that it would not conform to the OpenFormula standard)? To strangle ourselves with compatibility seems pointless. It's not crystal clear to me whether it would be better to namespace unique functions or just assume that implementors will provide a flag in the ui for 'only list functions compatibile with ...'. The same problem arises between versions. Backwards compatibility may be desireable, but how can we commit to a unchanging standard for the duration of the product ? By that logic we could never add a new feature for fear of breaking backwards compatibility. As long as users are warned 'this workbook uses features newer than version foo' they will make the trade off themselves. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
