Re: [office-formula] Our next adventure: Types and conversions

["Tomas Mecir" <mecirt@gmail.com>]

On 6/2/06, Eike Rathke <erack@sun.com> wrote:
> > Well, possibly, but basing on the problems that we now face, it does
> > sound like they have a reason for being that way.
>
> Legacy and sloppiness.

Hmm, it doesn't seem to be that easy. Well, to me, at least.

> Easy to solve: VALUEL( v; decimalseparator [[;groupseparator [;dateseparator]] ... )

Do all locales use Arabic 0..9 numbers ?
What if the parameter is not a number ? People may want to call this
on a date value, too. Having something like DATEVALUE would not solve
it fully, because dates are a more complicated thing than numbers, due
to different ordering, fact that monthes have long names, and whatnot.
You cannot supply full definition of a locale as parameters :)

> Only that conversion number->text is not as critical as conversion
> text->number is. Number->text conversion that includes separators is
> mostly used for display purposes to produce "nice" invoices and such.

Aye, mostly. I may be getting into technicalities here, but someone
may depend on the conversion being a certain way, then blame the app
when locale changes. I know this is a different, and less serious
problem, but it still stems from the same base.

As a summary, our problem at hand is choosing from two evils:

Evil 1: exchanging documents amongst locales requires compromises. In
particular, not to use string->number conversions, or use them in a
limited way (entering numbers in C-locale only, and the like). This is
what I am proposing.
This makes things easier for people who don't need locale conversions,
and it allows better manipulation with string values that hold a
number. Joe the User is only affected if this includes locale
conversions, otherwise, even if he does enter a number into a text
cell, it "just works".

Evil 2: documents are implicitly saved in a way that makes
cross-locale exchanging of documents easy.
Requires limitations of functionality in order to achieve this,
namely, disabling automatic string->number conversions, as well as
being able to define a set of attributes that can define each and
every locale (to be saved as parameters for VALUEL). This also has to
be presented to the user in some way, otherwise he will be confused
why two VALUEL calls that LOOK the same, don't BEHAVE the same - they
have hidden parameters, each of them specifying another locale.
Makes it easier for Joe the User who wants to exchange documents
cross-locale, and harder for everyone else, as they have to reformat
text cells if numbers are to be entered, and advanced users must use
more complicated syntax to get numbers from strings.
This approach is what Eike suggests.

So, the whole issue revolves around cross-locale exchange of
documents, nothing more, nothing less.

Now, first of all, am I missing something here ?
Next, do the two options look very much like they come from someone
who is biased towards one of them ? :) If so, how would a more
objective version look like ?
And, finally, is functionality more important than cross-locale
portability, or is it the other way round ?

/ Tomas