--
You received this message because you are subscribed to the Google Groups "gosu-lang" group.
To post to this group, send email to gosu...@googlegroups.com.
To unsubscribe from this group, send email to gosu-lang+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/gosu-lang?hl=en.
Long ago, back in the mists of time, we had made the decision that in
Gosu (then called GScript), all property accesses should be null-safe,
such that x.Y.Z would return "null" if x or x.Y evaluated to null.
It's often convenient, but we eventually decided that it really wasn't
a good idea to do that in all cases, since it can easily mask bugs.
By that point, though, we couldn't change that in Guidewire's code,
since it would blow up customer code pretty severely, so instead left
the behavior in the Guidewire version of Gosu, while in Gosu CR we
don't do that. In community release (i.e. "open source", though the
source isn't yet published) Gosu, you have to explicitly use the ?.
operator to do null-safe property accesses. So your code throws an
NPE if you try it with the latest Gosu CR release, but will print 0 if
you use a?.length. ?. works for method calls as well. That's one of
a few things that we've effectively tightened-up in Gosu CR relative
to Guidewire Gosu. There are a lot of implicit coercions that we
disallow in Gosu CR, and as of the latest 0.9 build (0.9-12 is what we
just released, I believe), Gosu CR is now case-sensitive (at long
last), another historical decision that we've been working for years
to reverse, but can't easily do in Guidewire products without breaking
backwards compatibility.
Explicit-safe property access or method calls will, for primitives,
return 0 for ints and false for booleans, and null for object types.
The "implicit" null-safe property paths in Guidewire Gosu behave
slightly differently with regard to primitives for the sake of sanity
(especially around arithmetic and comparison operators).
-Alan