Jody Goldberg wrote:
You've identified
1) Compatibility with other spreadsheets
2) Compatibility with older versions of OOo/SO
3) Avoiding conflicts with future OpenFormula spec
There are several things we can do, but they will require us to nail
down more detail on (2). Loading an old file (sxc or ods) should
generate the same result in newer version of OOo as much as
possible. What is less clear is what to do when loading a file
generated with the compatibility extensions into older versions.
For the types of changes being discussed there is no way we can
guarantee consistency without creating yet another file format
option which would quickly get unwieldy. Once this restriction has
been accepted there are several areas to look at.
Additional flags stored with the document aren't the only option. Others
include:
- Different versions of functions (as you mention with ADDRESS/INDIRECT)
- Optional parameters, as in FLOOR/CEILING
- Explicit conversion functions for different types (e.g. string/number)
All of these certainly come with their own problems, but let's not
discount them too quickly, just to come to the conclusion that no
solution exists and we have to ignore requirement 2.
That said, some notes on the individual cases:
1) Missing arguments
=ADDRESS(1,2,,1)
I've got some work on this that I'd like to discuss at some
point. This is a safe addition. No existing spreadsheet could
be impacted (ignoring bugs in the transition).
Sure. This is one of the things that we haven't done so far solely for
time reasons.
2) Support for XL addressing modes
eg R1C1 and sheet1:sheet2!A1:B2
Again there is a CWS with work towards this that has had some
review. Adding this starts to get interesting. In that some of
the worksheet functions are directly impacted. For the time
being I have created ADDRESS_XL and INDIRECT_XL to use the new
parsers, and left the old versions as the defaults.
Unfortunately that makes us inconsistent with all the MS Excel
books out there for users entering formulas. It seems
preferable to use the new functions as the defaults, and have
the sxc/old-ods importers do the mapping.
The issue of selecting a default is quite similar to file compatibility:
We have existing users, and we don't want to force them to re-learn.
3) Use less obscure error codes.
It's pretty clear that Err.503 provides less information than #DIV/0
or even than #NUM!. Doing this would create an incompatibility,
operators and functions would return different errors in the new
version. That does not seem particularly onerous. We could do
some mapping in ERRORTYPE which was one of the few safe
mechanisms for examining error results to help minimise the
incompatibilities if necessary.
Two separate issues here: The numerical error values, including the
selection of the right one for each operation, and the display of a more
helpful message than the error number.
4) Create a real boolean type.
Faking things with some formating tricks and the use of TRUE()
and FALSE() is not sufficient. Without an internal bool we can
not do compatible implicit type conversions. It's hard to
gauge how much incompatibility this change will generate.
Adding the type itself is a small change relative auditing all
of the iterators to see when to do implicit conversion and when
not. Unfortunately this binary choice (no pun intended). OOo
can only be compatible with one set of arbitrary conventions.
Either we match > 99.9% of existing spreadsheets or we do not.
The prospect of inserting a 'calc mode' flag and supporting
multiple conventions in every function that uses an iterator is
not maintainable.
Introducing a new cell type affects far more than just formula
calculation, from number formats to API (including add-in functions).
From a "price/performance" point of view, this issue seems quite far
down the list.
5) Implicit conversions of strings to values
=1+"2005/Dec/20" => ??
While this is controversial for other reasons (it makes
calculation locale dependent) it is actually a fairly safe
change. Old files would have generated errors in the cases that
need to be considered. It seems unlikely that anything was
depending on that behaviour. The lack of this feature has
significantly more dire consequences as values that were
generated in other spreadsheet no long calculate.
Constant strings are one issue. The more common problem seems to be text
cells. It is at least conceivable that someone has put a text like
"zero" into a cell and expects "=A1*2" to yield 0, not an error. This
wouldn't be any more "wrong" than a text "123" in a cell.
That seems a reasonable set to start with at the global level.
All of the operators and functions also need to be audited. Novell
and Gnumeric have the start of some test workbooks that can be
merged with the basic work done for the google summer of code
project. However, that is a different magnitude of change and
should be dealt with separately.
And again: Collecting problems is only one part, we shouldn't give up on
looking for solutions too quickly.
Niklas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
