On Jan 14, 2009, at 4:44 PM, Kris Zyp wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Brendan Eich wrote:
On Jan 9, 2009, at 3:08 PM, Kris Zyp wrote:
The counter-argument is strong:
typeof x == typeof y => (x == y <=> x === y)
but 1.1 != 1.1m for fundamental reasons.
I understand the counter-argument, but with such an overwhelming
number of typeof uses having far easier migration with "number",
Migration how? You'll have to change something to "use decimal" or
s/1.1/1.1m/. Only once you do that can you be sure about all
operands being decimal.
And I am sure our users will do that and pass decimals into our
library functions.
I'm not disputing that. Straw man?
I'm assuming it would be "bad" in the Dojo code you've looked at if
1.1 came in from some standard library that returns doubles, and was
tested against 1.1m via == or === with false result, where previous
to decimal being added, the result would be true.
I am not aware of any situations in the Dojo codebase where this would
cause a problem. I can't think of any place where we use an
equivalence test and users would expect that decimal behave in the
same way as a double. Do you have any expected pitfalls that I could
look for in Dojo?
Sure, starting with JSON (see below).
I can't possibly see how the desire to preserve this property is
more
important than better usability for the majority use cases.
You really need to show some of these use cases from Dojo. I have a
hard time believing you've ruled out mixed-mode accidents.
Ok, sounds good, I will be glad to be corrected if I misunderstanding
this. Here are some of the places where I believe we would probably
add extra code to handle the case of typeof checks where decimal
values may have been passed in by users, and we would want the
behavior to be the same as a number:
As I have mentioned before, we would need to change our JSON
serializer to handle "decimal":
http://archive.dojotoolkit.org/nightly/dojotoolkit/dojo/_base/json.js
(line 118)
You need to change this in any case, since even though the JSON RFC
allows arbitrary precision decimal literals, real-world decoders only
decode into IEEE doubles. You'd have to encode decimals as strings and
decode them using domain-specific (JSON schema based) type knowledge.
Our parser function would need to add support for "decimal"
http://archive.dojotoolkit.org/nightly/dojotoolkit/dojo/parser.js
(line 32)
You're right, this parser would need to be extended. But if typeof
1.1m == "number", then str2ob around line 52 might incorrectly call
Number on a decimal string literal that does not convert to double
(which Number must do, for backward compatibility), or else return a
double NaN (not the same as a decimal NaN, although it's hard to tell
-- maybe impossible?).
It seems to me you are assuming that decimal and double convert to and
from string equivalently. This is false.
Matrix math handling for our graphics module:
http://archive.dojotoolkit.org/nightly/dojotoolkit/dojox/gfx/matrix.js
(line 88 is one example)
I couldn't be sure, but by grepping for \.xx and \.yy I think I saw
only generic arithmetic operators and no mode mixing, so you're
probably right that this code would work if typeof 1.1m == "number".
Someone should take a closer look:
:g/\.xx/p
this.xx = this.yy = arg;
matrix.xx = l.xx * r.xx + l.xy * r.yx;
matrix.xy = l.xx * r.xy + l.xy * r.yy;
matrix.yx = l.yx * r.xx + l.yy * r.yx;
matrix.dx = l.xx * r.dx + l.xy * r.dy + l.dx;
D = M.xx * M.yy - M.xy * M.yx,
yx: -M.yx/D, yy: M.xx/D,
dy: (M.yx * M.dx - M.xx * M.dy) / D
return {x: matrix.xx * x + matrix.xy * y + matrix.dx, y:
matrix.yx * x + matrix.yy * y +
matrix.dy}; // dojox.gfx.Point
M.xx = l.xx * r.xx + l.xy * r.yx;
M.xy = l.xx * r.xy + l.xy * r.yy;
M.yx = l.yx * r.xx + l.yy * r.yx;
M.dx = l.xx * r.dx + l.xy * r.dy + l.dx;
:g/\.yy/p
this.xx = this.yy = arg;
matrix.xy = l.xx * r.xy + l.xy * r.yy;
matrix.yx = l.yx * r.xx + l.yy * r.yx;
matrix.yy = l.yx * r.xy + l.yy * r.yy;
matrix.dy = l.yx * r.dx + l.yy * r.dy + l.dy;
D = M.xx * M.yy - M.xy * M.yx,
xx: M.yy/D, xy: -M.xy/D,
dx: (M.xy * M.dy - M.yy * M.dx) / D,
return {x: matrix.xx * x + matrix.xy * y + matrix.dx, y:
matrix.yx * x + matrix.yy * y +
matrix.dy}; // dojox.gfx.Point
M.xy = l.xx * r.xy + l.xy * r.yy;
M.yx = l.yx * r.xx + l.yy * r.yx;
M.yy = l.yx * r.xy + l.yy * r.yy;
M.dy = l.yx * r.dx + l.yy * r.dy + l.dy;
I did not look at other files.
Actually there are numerous situations in the graphics packages where
a decimal should be acceptable for defining coordinates, scaling,
etc.:
http://archive.dojotoolkit.org/nightly/dojotoolkit/dojox/gfx/
Only if never compared to a double. How do you prevent this?
Charting also has a number of places where decimals should be an
acceptable form of a number:
http://archive.dojotoolkit.org/nightly/dojotoolkit/dojox/charting/
For example:
http://archive.dojotoolkit.org/nightly/dojotoolkit/dojox/charting/action2d/Magnify.js
(line 22)
I will look at these later as time allows, pending replies on above
points.
Again, I understand there are difficulties with typeof 1.1m returning
"number", but in practice it seems we would experience far more pain
with "decimal".
Trouble for you Dojo maintainers but savings for users. You may have
to do a bit more work to avoid imposing bugs on your users. That's
life in the big Dojo city.
/be
- --
Kris Zyp
SitePen
(503) 806-1841
http://sitepen.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkluhukACgkQ9VpNnHc4zAyaLgCeLbJeVvoLd1ypvK9uiyfO0Jhw
RuEAoKNZQeBKKfHzoupEdY+Nv16Lk+ch
=pV7U
-----END PGP SIGNATURE-----
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
