[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-formula] Conversions (BIN2DEC and friends) - how muchto spec?
Rob Weir: > Are these functions [BIN2DEC etc.] assuming a particular > byte ordering? Or are the machine-dependent? No, they don't assume a particular byte order. They're still AWFUL. Andreas J Guelzow said: > At least the Gnumeric developers believed it necessary > to implement the same syntax as Excel to allow users to > easily migrate from Excel to Gnumeric. I would assume that > something similar is true for OOo. Actually, OOo uses a SLIGHTLY different display syntax; it uses ";" as the parameter separator. For internationalization this is very sensible; your decimal separator can be "." or "," and there's no ambiguity. But that's a nit. Basically, I agree with you, applications tend to agree on syntax (that's a GOOD thing!). And as you noted, what matters is that we can exchange data. KSpread uses "==" instead of "=" for "is-equal-to". Corel Quattro Pro has "skins", which let you PICK the display/data entry syntax. As long as we agree on how to share data, the display format is less important. > Of course for the Openformula file format it is, imho, > more important to make sense... Yes. I said: >> We have three choices that I can see: >> 1. Don't include them in the spec. Clean, but then we don't >> provide an upgrade path... >> 3. Include them, including the weird semantics that everyone >> implements (and people probably depend on), >> but also include "nicer" functions with >> saner semantics.... >I would prefer #1. If we indeed want to do number 3 we should use a >different namespace for them akin of > >DEPRECATED.BIN2DEC("101") or >NONSENSE.BIN2DEC("101") That'd be plausible. I like the idea, though not the example names: * NONSENSE describes how I feel, but I think we should be not quite so vindictive in the official name. * And over time, other functions we now think are marvelous might be deprecated. I don't think we should call it "DEPRECATED", because there will someday be deprecated functions that aren't in that group. How about LEGACY? E.g., "LEGACY.BIN2DEC...". The LEGACY group would be a set of functions from older spreadsheets that COULD be implemented as an aid in transitioning to OpenFormula from non-OpenFormula... not a group for all deprecated functions. We could then not _mandate_ support for them... but if you DO support them, here is their syntax. I doubt "LEGACY" will ever become a top-level-domain name in DNS. >Realistically, they come from Excel so >COM.MICROSOFT.BIN2DEC("101") >would make more sense but of course we should not define >functions in that namespace. I also would prefer not to. If it's sensible we COULD do so; they are, after all, in Excel. It's not clear to me that they originated in Excel, though; I haven't tracked down their history to determine the guilty party. Anyway, I think we should define a different space like LEGACY. That would help, and avoids defining someone else's namespace. And not all LEGACY functions will come from Excel :-(. --- David A. Wheeler