On Mar 13, 2008, at 11:58 PM, Q wrote:
> I think wolips is right in marking this as being unable to validate.
> Your return type for foo.bar() is _Bar, not Bar, so it does not have
> a baz() method. If the only way to access foo.bar().baz() is, as you
> say, with an unsafe type case then you should expect to need to add
> a //VALID statement.
In Java, what is an alternative to an unsafe type cast? Use
reflection to check whether foo.bar() returns an app.Bar type? If so,
send app.Bar a baz() message, but if not, throw an exception, etc.?
> Wolips does static analysis using type information, if your key path
> cannot be expressed without type casts wolips cannot validate it.
> That doesn't mean WO can't resolve it at runtime, only that it
> cannot be validated using static analysis.
Kind of a pain when one uses an extensive class hierarchy. Adding
"// VALID" certainly does nothing to improve safety, but it is a pain
to go through many WOD's that have worked without error for years when
under Xcode/WOB. Seems like other than "// VALID", the only
workaround would be to add a baz() method to foo() that does the
introspection check, and then change the binding to foo.baz.
> Use //VALID or change your return type of foo.bar() to Bar instead
> of _Bar
>
I wonder what would happen if I put database._Bar in a different
package from database.Bar and renamed it database.base.Bar. Would
that trick the binding validator?
Aloha,
Art
This archive was generated by hypermail 2.0.0 : Fri Mar 14 2008 - 17:50:45 EDT