I'm all for new features, but have a preference to turn it on or off.
With keypaths, have it on by default and with the refactoring, maybe
have it off by default. If you had it on by default I think an alert
panel to let the user know that it may break would be good so they
can cancel the operation.
What about having a new view (as related view is probably not
appropriate) where you can see where a component is used is other
components, this would at least aid in the manual refactoring.
Greg
On 16/10/2005, at 6:37 AM, 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?
>
> 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.
>
> 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)
>
> ms
>
>
This archive was generated by hypermail 2.0.0 : Sun Oct 16 2005 - 18:43:17 EDT