> 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. 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.
>
>> Is there possibly a class path problem that might be causing
>> this? Any other suggestions?
>
> Use //VALID or change your return type of foo.bar() to Bar instead
> of _Bar
"What he said" :)
But yeah, I'm somewhat limited in what I can do here ... For most
types, I validate based on pure static analysis based on the type
rules of Java (meaning, if you have to cast, then I don't know what
it's supposed to be). The real question is whether you want
validation to tell you if it's MAYBE ok, or do you want validation to
tell you that it's DEFINITELY ok. There are two types that are an
exception in this regard, and that's WOApplication and WOSession.
WOApplication and WOSession actually compute a SUBclass hierarchy
instead of the SUPERclass hierarchy, because as it turns out nearly
100% of the time you don't mean "WOApplication" or "WOSession" as the
return value of application. or session. would lead static analysis to
believe. But this works out better, because nearly ever time there is
only a single subclass of WOSession or WOApplication, so it sort of
works out. This can actually be tripped up, though. You can see it
if you declare two WOSession subclasses in your reachable package tree
for the project -- it has no idea which one it should use, so you get
combined results, which means validation can lie in this. This would
be the problem ALL the time if we did this on every type. A simple
example of this is a method that returns NSArray. Allowing any subtype
to be valid would mean that validation would show NSMutableArray
methods as valid on an NSArray, which would be an example of what you
would want validation to catch instead of allow.
There's this constant struggle in the validation code ... KVC is
typeless and really loose and Java is very strict. Trying to find the
balance that allows the expressiveness of WO/KVC but also provides
some semblance of type-safety is very tricky. There are tons of
configuration tweaks, though, so you can tweak quite a bit of this
behavior. I could maybe make "consider subtypes valid", but it's
actually a substantial performance cost to enable this, because
computing a subtree is way more expensive than a supertree (you can
imagine -- supertree just walks the explicitly listed names back up vs
hunting across every reachable type). Incidentally, this same thing
happens when people write KVC (or component references) in a framework
that don't resolve until runtime (like referring to a component that
doesn't exist except in the app). All I can say is that validation
shows you red flags and code smells. They may be sort of common
behaviors, but they're not SAFE behaviors, and validation is trying to
keep you safe.
ms
This archive was generated by hypermail 2.0.0 : Fri Mar 14 2008 - 09:47:32 EDT