ES Decimal status
mjs at apple.com
Wed Sep 24 07:45:10 PDT 2008
On Sep 24, 2008, at 7:31 AM, Sam Ruby wrote:
> Maciej Stachowiak wrote:
>> On Sep 24, 2008, at 3:33 AM, Mike Cowlishaw wrote:
>>>> and in particular they don't call it on the index in an array
>>> This is true. But that in itself is not the problem. Currently,
>>> should a
>>> programmer write:
>>> it's assumed that the second case was an accidental typo and they
>>> did not mean to type the extra '.000'. The problem occurs at
>>> that point,
>>> on the conversion from a decimal (ASCII/Unicode/whatever) string
>>> in the
>>> program to an internal representation. When the internal
>>> cannot preserve the distinction (as with binary doubles) there's
>>> not much
>>> that can be done about it. But a decimal internal representation
>>> preserve the distinction, and so it should - 1m and 1.000m differ
>>> in the
>>> same was a "1" and "1.000". They are distinguishable, but when
>>> interpreted as a number, they are considered equal.
>> I'm not sure what you are getting at. a and a[1.000] refer to
>> the same property in ECMAScript, but a[1m] and a[1.000m] would
>> not. Are you saying this isn't a problem?
>> I would agree with Waldermar that it is a serious problem. Not so
>> much for literals as for values that end up with varying numbers
>> of trailing zeroes depending on how they were computed, even
>> though they are numerically the same. Certainly it seems it would
>> make arrays unusable for someone trying to use decimal numbers only.
> "broken", "unusable". Given superlatives such as these, one would
> think that code which would change in behavior would be abundant,
> and readily identified.
I would not expect there to be a wide body of existing code using the
decimal extension to ECMAScript, let alone trying to use it for all
browsers. Such code would not work at all in today's browsers, and has
probably been written by specialist experts, so I am not sure studying
it would show anything interesting.
More information about the Es-discuss