I think String.valueOf(x) is ok, because if this happens at runtime, it will pick up the JS VM toString behavior. If it is handled at compile time, than it is evaluated with JsStaticEval. "" + 1.004E5 -> 100400. I think the real problem might be differences that might crop up in hosted mode.
Leaving the JsStaticEval problem aside, I feel that setZIndex() coercing number to String is a bug, and it should be using setPropertyInt(). -Ray On Mon, Apr 12, 2010 at 8:21 AM, John Tamplin <j...@google.com> wrote: > On Mon, Apr 12, 2010 at 10:59 AM, Lex Spoon <sp...@google.com> wrote: >> >> Interesting subthreads aside, does the change in this patch LGT everyone? > > I don't know enough to comment, so FHMP. > >>> >>> Well, not if we are using it in contexts where it is expected to be all >>> digits, as in the original bug. >> >> True. >> In this particular subthread, the context is JsToStringVisitor. This class >> already discards whitespace and drops comments. It also does rewrites such >> as 1.23456E5 to 123456, and those are more than fine. Emit it whichever way >> is shortest. > > I was specifically talking about our JRE emulation, which is where > String.valueOf comes in. I am wondering if we have a similar problem to the > problem you are fixing in the compiler -- ie, someone does > setWidth(String.valueOf(width) + "px"), is it possible the resulting string > will be "2e10px" etc, which will be totally wrong? > -- > John A. Tamplin > Software Engineer (GWT), Google > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors To unsubscribe, reply using "remove me" as the subject.
