OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office-formula] Semantics


On 3/1/06, Eike Rathke <erack@sun.com> wrote:
> Hi Tomas,
> On Wed, Mar 01, 2006 at 09:45:01 +0100, Tomas Mecir wrote:
> The hell of strings being sometimes interpreted as numbers and sometimes
> not. The hell of locale

Hmm... So, to sum it up, the major problem with allowing automated
string->integer conversions is locale, right ? But then, if we attempt
to make everything locale-independent, we necessarily fail. What if
the user types in VALUE("12`345,67"), or any of the other examples you
gave ? What about DATEVALUE and similar functions ? Then the results
still won't be the same on different locales, right ? So by allowing
="3"+3 to exist, we don't make locale-related problems bigger.

> Which ones do what?

Well things like perl or php don't have datatypes and convert
on-the-fly, as needed ...

> > How would you do these things, then ?
> You better don't. Numbers are numbers, and text is text. User input is
> parsed according to the input locale, after that text content shouldn't
> be reparsed. If the user designs a document the way formulas concatenate
> strings to form numbers that have to be parsed in numeric context it is
> his duty to get it right not to use locale dependent delimiters or to
> not spread the document to someone who works using a different locale.
> Else it may break. You can't prevent that under all circumstances.

Like I say above, even simple VALUE can create these problems.

> > I think OOo supports things like "3"+3 is 6, right ?
> > This is locale-dependent as well ...
>
> And I wish it was never introduced. We might even remove it. But that's
> just my personal opinion.

Well it MIGHT make sense, but like I say, we can restrict locale-based
problems a bit that way, but never remove them.

> > > Bear in mind that AVERAGEA(range) does not convert strings to numbers,
> > > it treats them as zero. This is a different functionality.
> >
> > Well in my opinion, it should attempt conversion, and treat them as
> > zeroes only upon a failure.
>
> On failure it should generate an error instead. My opinion.

So I take it that string->number conversions are okay in functions
with the A suffix ?

/ Tomas


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]