[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-formula] Our next adventure: Types and conversions
David A. Wheeler wrote:
I'll try. I'm not proposing a hidden function - so I don't think we're thinking on exactly the same lines yet.Hmm, this is yet another approach, one I hadn't accounted for (or thought of). You're right, you could completely hide this via functions, which might not be displayed on some systems (due to their semantics). One challenge is that you may have ranges of numbers, and all functions that take ranges must specify the difference too. The traditional way has been to append an "A" at the end of some function names; that won't work for all. I would add that you probably want a "VALUE-like function, but don't show it to me", since people will want a VALUE() that shows, too. This might really be a good solution. Can you post an expansion on this idea, asap?
In the most simple form I'm proposing that we implement the VALUE function with a locale parameter viz VALUE(string, locale).
My reasons why this will work are:
Implementations may choose to hide the locale from the users, and where the locale matches the machine locale that makes sense (this is not part of the spec). What implementations do with functions containing another locale is up to them. To be completely compliant they should perform the conversion with the specified locale settings. As part of the spec I suggest we allow implementations to support value in the machine locale only provided they warn the user before switching locale during file open.
Therefore, I don't think we have a VALUE and VALUEA function, we simply have a VALUE function. The specification may call it VALUEL and not actually support the VALUE function at all, in order to distinguish between the common function in use and the specification. In that sense the function may be hidden.
--- Richard Kernick