>> 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.?
So what Java (and validation) want is a proper interface. If you're
binding to something.baz (I'll pay you $5 at WWDC for examples other
than foo/bar, btw :) ), every subclass should have .baz, or it's not a
"valid" expression. I know it's valid in terms of KVC, but if I allow
this in the validator, then it means that every method called is
allowed, and there is no value to validation. The slight variation of
this would be (like I was mentioning how WOSession works) that I could
restrict you to the subclass hierarchy, but I personally find this to
be pretty misleading. Validation is going to say "hey, sure, you're
safe, don't worry" and then your app explodes at runtime because you
bound to some method that only SOMETIMES exists.
As I was a Java programmer first and WO programmer second, my
recommendation is to make all the types that can pass through that
point implement a common interface. For cocoa / original WO people,
though, I recognize this is an ugly thing to say :)
The other option is to implement a cover method somewhere ... for
instance, your component could implement the baz method and just use
NSKVC.Utility.valueForKey(..) on the object and then you could bind to
this cover method. This would tell WOLips that you INTEND this
behavior, that you're not just making a mistake and binding to some
non-existent method. Obviously if this is particularly annoying and
you use this technique all over the place, you could just turn off
validation.
>> 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.
They work in WOLips also, but but WOLips is telling and what Xcode/WOB
SHOULD have been telling you, is that what you're doing is not safe.
You're declaring a dependency on a method that MAYBE exists. If you
want to write code this way, you either need to mark the references
as // VALID, or you should turn off binding validation because you're
writing code in a way that is impossible to actually validate anyway.
I don't believe you need any reflection here, though. Presumably you
have polymorphic types here, just make the types that can pass through
your code all of a common interface, that would be The Java Way(TM) of
correcting this problem, which would allow the validator to prove that
your bindings are correct.
>> 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?
WOLips is not name based, it's really java type-based (it's sitting on
top of the type system of Eclipse internally), so it will know and see
through your clever ruse. Your classes are linking to specific
classes, not just their simple element names.
ms
This archive was generated by hypermail 2.0.0 : Fri Mar 14 2008 - 18:39:06 EDT