Scott,
Fair enough (RPC use case), but do you think the warning should be a little more explanatory and stronger like "Don't *EVAH* DO DIS unless you know what you're doing." :) My intuition is that in 99% of the cases, the user will be surprised (because they didn't read the release notes on long emulation) and the code will be buggy.
One last option:
d) auto-coerce to double, warn on loss of precision
avoid coercion with annotation (RPC case)
public void foo(@DontCoerce long x, long y) /* ... */
x gets passed through (RPC case), y gets coerced.
I think I'm ok with a warning, but I think the warning needs to be verbose because I bet 9 out of 10 users won't read the 1.5 release notes/docs on longs, so may as well educate them during compile cycles. :)
Also, would there be any benefit in defining a new time stamp that is
the number of milliseconds since the start of the app? It would
reduce the necessary range quite dramatically--it might fit into an
int, and would certainly fit into a double without loss of
precision--but I don't know if it would be useful for anything.
Ian
--
Tired of pop-ups, security holes, and spyware?
Try Firefox: http://www.getfirefox.com
I think your decisions make a lot of sense, especially with the
rationales given. It did make me wonder, though--what kind of
performance hit is 1.5 going to introduce to long math?
Also, would there be any benefit in defining a new time stamp that is
the number of milliseconds since the start of the app? It would
reduce the necessary range quite dramatically--it might fit into an
int, and would certainly fit into a double without loss of
precision--but I don't know if it would be useful for anything.
It did make me wonder, though--what kind of
performance hit is 1.5 going to introduce to long math?
Is there actually an statical analysis to determine if a long field
will be never stored with values out of the integer range?