My 2 cents...
On Oct 15, 2005, at 1:37 PM, Mike Schrag wrote:
> I'd really like to implement better binding checks that will
> actually give you an error if a keypath you use is invalid ... The
> problem is that WO supports dynamic keypaths (meaning, the key you
> use doesn't actually have to exist as a method or field in a
> class). My intuition is that this is the exception not the rule,
> though, and that a lot of good could come from verifying that your
> keypaths don't have spelling errors, etc. The problem is that
> while it may be the exception, it's still perfectly valid and
> certainly DOES occur. Which means if I were to think about
> implementing something like this, I would have to address the
> problem somehow. The issue of refactoring has similar
> difficulties, which is I can't guarantee that refactoring will work
> 100% because I don't have static type information in the WOD (for
> instance, you say session.myValue and myValue is actually in the
> subclass of WOSession, not WOSession itself as the static type
> information tells me). So several questions:
>
> 1) Would you rather me just leave it alone?
>
This is a common problem, so some way of verifying the keypaths would
be good. You could even make it a special "analyze and report"
function.
> 2) If I do attempt to deal w/ keypath verification, how do you
> propose addressing dynamic keypaths? Eclipse has a mechanism for
> specifying that strings in a plugin are not to be externalized by
> putting a special comment on the line ( like // $NLS-1$ or some
> such syntax). I was tossing around the idea of being able to turn
> off keypath verification on a binding-by-binding basis by putting a
> special marker (like // NOVERIFY or something). I'm open to other
> ideas, though.
>
I like that. Adding // DYNAMIC to the end would not only allow the
check to be bypassed, but it would server as documentation for the
future.
> 3) Refactoring is impossible to get right 100%, so would you rather
> have a partial refactoring that might leave problems or no
> refactoring at all (on the theory that if you can't trust it it's
> not worth doing). The difference is that it would only ever help
> you -- meaning, i would never refactor a new bug in, there are
> just cases that I can't know and therefore can't refactor, so I
> would only miss things (which would leave you no worse off than you
> were BEFORE the refactoring in the worst case)
I'm lazy so I would prefer partial refactoring support to none at
all. Less work, better. :-)
Chuck
-- Coming in 2006 - an introduction to web applications using WebObjects and Xcode http://www.global-village.net/wointroPractical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects
This archive was generated by hypermail 2.0.0 : Tue Oct 18 2005 - 13:26:31 EDT