[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]