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 2/28/06, Eike Rathke <erack@sun.com> wrote:

> > First of all, my fundamental principle: as far as the user is
> > concerned, there are no datatypes. Everything automatically gets
> > converted to what is expected.
> This is exactly the hell in which the approach of the one big player
> brought us..

Really ? What kind of hell ? I don't see any problem with this
approach - after all all those "high-level" programming panguages do
the same ...
Or, do you see any reason why strings shouldn't be treated as numbers
for values like "3", other than performance reasons ? Not things like
"Hi", bailing out with an error there does make sense (although my
implementation doesn't do it at the moment).

> Now consider that you pass the document to a colleague who works with
> a different locale. Maybe it breaks.

How would you do these things, then ? Is it even -possible- to design
things so that they're locale-independent, without majorly limiting
functionality ? I think OOo supports things like "3"+3 is 6, right ?
This is locale-dependent as well ...

> > I realize this may create problems, but it follows my fundamental
> > principle of no datatypes.
> Well, it's your decision, but then you'd have to write COUNTA to the
> file format instead of COUNT. And you wouldn't be able to correctly read
> a file that uses COUNT.

If we decide that the fileformat should distinguish between COUNT and
COUNTA, then yeah. You raise some valid arguments here, but I'm not
convinced, as both solutions seem to have problems. Either restricted
functionality, or problems with locale. Which is more important not to
have ? Who can decide that ?

> 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.
And see, another inconsistency. =(3+"Hi")/2 should raise an error,
AVERAGEA on two values, "Hi" and 3, will yield 1.5 ...

/ Tomas


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