Re-rolling the patch with changes just to JsoSplittable and
SplittableTest to fix the Safari4 test failure and improve the
robustness of the type detection code.
http://gwt-code-reviews.appspot.com/1407802/diff/6001/user/src/com/google/gwt/autobean/client/impl/JsoSplittable.java
File user/src/com/google/gwt/autobean/client/impl/JsoSplittable.java
(right):
http://gwt-code-reviews.appspot.com/1407802/diff/6001/user/src/com/google/gwt/autobean/client/impl/JsoSplittable.java#newcode61
user/src/com/google/gwt/autobean/client/impl/JsoSplittable.java:61:
On 2011/04/07 19:05:04, cromwellian wrote:
As an aside, some optimizations in the GWT compiler seem to be able to
turn
"if(referenceType != null)" into if(referenceType). When this occurs,
if you
have the Splittable backed by directly by a non-null unwrapped false
value ("",
0, or boolean false), such checks fail. This means comparing a
JsoSplittable to
null, or sticking it into an API that might do so (e.g. collection)
can have
unpredictable results. This is fine as long as usage of the type is
strictly
controlled by you.
I ran into this with the numeric 0 value. My workaround is to always
object-ify returned values in getRaw(). There's a test for this over in
SplittableTest.
http://gwt-code-reviews.appspot.com/1407802/diff/6001/user/src/com/google/gwt/autobean/client/impl/JsoSplittable.java#newcode70
user/src/com/google/gwt/autobean/client/impl/JsoSplittable.java:70:
private static native Splittable create0(String object) /*-{
On 2011/04/07 19:05:04, cromwellian wrote:
You can use Object(string) to wrap and object.valueOf() to unwrap.
This avoids the case of
("" == false) -> true
and even more obnoxiously
Object("") == false -> true
since the empty string is coerced to false.
http://gwt-code-reviews.appspot.com/1407802/diff/6001/user/src/com/google/gwt/autobean/client/impl/JsoSplittable.java#newcode87
user/src/com/google/gwt/autobean/client/impl/JsoSplittable.java:87:
public native double asNumber() /*-{
On 2011/04/07 19:05:04, cromwellian wrote:
+this also works except false/true won't be coerced to 0/1
That's ok. It's intended that you should check isFoo() before calling
asFoo() if you don't already know the type. You'll get an exception in
DevMode since the relevant typed field will be null in JsonSplittable.
http://gwt-code-reviews.appspot.com/1407802/diff/6001/user/src/com/google/gwt/autobean/client/impl/JsoSplittable.java#newcode155
user/src/com/google/gwt/autobean/client/impl/JsoSplittable.java:155:
public native boolean isIndexed() /*-{
On 2011/04/07 19:05:04, cromwellian wrote:
This can fail if the json payload ever comes from the host page, e.g.
via a
JSONP request, because $wnd.Array != Array. I don't know if you intend
to ever
support that (e.g. take a JsoSplittable passed to a public API method
for
decoding) A check that works regardless can be found here:
http://perfectionkills.com/instanceof-considered-harmful-or-how-to-write-a-robust-isarray/
I can refit all of the isFoo() methods using this trick, which should
work regardless of primitive vs. object vs. cross-frame.
http://gwt-code-reviews.appspot.com/1407802/diff/6001/user/src/com/google/gwt/autobean/client/impl/JsoSplittable.java#newcode247
user/src/com/google/gwt/autobean/client/impl/JsoSplittable.java:247:
private native String stringifyFast() /*-{
On 2011/04/07 19:05:04, cromwellian wrote:
Caution, if the JsoSplittable ever has hashCode() invoked on it (e.g.
it is put
into a collection), a field of $H will be present and get serialized.
Added a test for this.
http://gwt-code-reviews.appspot.com/1407802/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
