>>Do we *want* it to do that?  Seems like this would show up with any 
kind of code update (it must be possible to trigger this problem using 
changesets as well, right?).  And whatever the code is that does the 
recompilation seems to handle the shadowed temp var methods just fine 
(it will update any other inst var refs if the order has changed, so 
it's not like those methods just get ignored).


If I had my druthers, I'd prefer it to work like the following (roughly based on the remove a method menu option in the browsers):
When a class change is made, the system scans for all possible conflicts.  If there are none, it just goes ahead and makes the change.
If there is a possible conflict, it counts up the number of them, and give you a choice about what to do:
1) Abandon the change (do nothing, including no change to the class)
2) Abandon the change, but look browse the potential conflicts.
3) Proceed with the change, but also browse the conflicts.
4) Just make the change, and if possible let the conflicts lie until later.

Along with this, if Monticello could capture the fact that there is a class change with consequences (potential conflicts), it could then scan ahead to find possible method changes that would mitigate these conflicts.  If it found them, it could go ahead and apply them, and the user would then not get the notification.  Something similar could also be done with change-set loading.

For update streams (which I bet also have this issue - although I can't prove it), care just needs to be taken to put the method changes into the stream before the class modifications.

Of course, if you have methods outside of the package or change-set that contains the class change that could conflict with the class change, well, it's time to prompt the user again.


____________________________________________________________
Free Poetry Contest. Win $10,000. Submit your poem @ Poetry.com!
http://ad.doubleclick.net/clk;6750922;3807821;l?http://www.poetry.com/contest/contest.asp?Suite=A59101