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

[Eike Rathke <erack@sun.com>]

Hi Tomas,

On Fri, Jun 02, 2006 at 14:16:44 +0200, Tomas Mecir 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.

Of course it isn't that easy, but to me it boils down to this point.
Interpreting text as arbitrary numbers was done because "other
spreadsheet applications" did it. Applications on the other hand
continued supporting that nonsense because of the sloppiness of users
and 3rd party applications who don't care getting their data in shape.

> >Easy to solve: VALUEL( v; decimalseparator [[;groupseparator 
> >[;dateseparator]] ... )
> 
> Do all locales use Arabic 0..9 numbers ?

Not necessarily.

> What if the parameter is not a number ? People may want to call this
> on a date value, too.

Ok, then we end up again with VALUEL(v;locale) as the clean way, which
I'd prefer anyway, but as stated it will not work if the locale is
unknown to the application, which was the only reason I came up with
that suggestion.

> 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 :)

Seems we'll have to draw a line somewhere. Either full support of known
locales with the drawback of an unsupported locale in the reading
application (preferred), or partially support of separator combinations
with the drawback that not everything could be converted. Interpreting
text on the fly without locale context is evil, no matter how you turn
it around.


> 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.

Explain that to the user who does not work in an en_US or similar
locale. IMHO this approach does not solve anything.

> 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".

So it would work for en_US people and suck for others. That's not our
goal, I guess.


> 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).

Where to define those attributes?

> 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.

I don't see why the VALUEL() calls should have hidden parameters,
instead of having the parameter explicitly determine a 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.

?!? I don't think so..  I seconded a VALUEL(v;locale) function that even
may be used by the user if she wants text to be interpreted in
a cross-locale environment. Upon first save, standard VALUE(v) calls
could be automatically converted to VALUEL(v;locale) with locale being
the same locale the user worked with, but IMHO should not be converted
back to a VALUE(v) function upon loading the document.

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

This "nothing more" is significant.

> Now, first of all, am I missing something here ?

It seems we have different priorities and maybe are regarding different
types of users.

> And, finally, is functionality more important than cross-locale
> portability, or is it the other way round ?

That's not the question. We need functionality with cross-locale
support.

  Eike

-- 
Automatic string conversions considered dangerous. They are the GOTO statements
of spreadsheets.  --Robert Weir on the OpenDocument formula subcommitee's list.