Hi.
1. Open up a browser. Go to the System-Support class category. Stand over SystemDictionary. Start editing #openSourceFiles. Save something like more comments. Edit a bit more. Don't save.
2. Open up another browser. Go to the same class category. Add a class named AuthorInitialsManager.
3. Go to the first browser. Try to abort your newly edited method by cancelling the changes.
Bang! You can't because the browser will try to find the compiled method for #openSourceFiles in the wrong class. And you can't save either, so the browser is somewhat useless. Ok, the problem in this case was that when I tried to save, the compiler didn't find the variable names in the wrong class. So I added the variable names, saved, killed the browser, deleted the variables and the method.
I don't know how to fix this.
Andres.
Andres -
...browser consistency problem...
I don't know how to fix this.
This problem dates back to the release of Smalltalk-80. There are several ways to fix it, but none are exactly simple. We (Ted K mainly) had a pretty complete solution for this before 2.0, but we decided to wait until the Pluggable and Morphic conversions were in place so it would work for both worlds.
The most common problem is that you can be looking at a piece of code that is out of date and not know it. Your problem is less common, but can be somewhat nastier as you discovered. I believe your problem could be fixed fairly easily if the browser keeps its own copy of the System organization. Then adding or removing classes in another browser would not invalidate the browser list indices.
The full solution that we have in mind is... 1. Keep a pointer to the method being browsed. If that ever differs from a re-retrieval, then the method got changed in some other browser. We would check this whenever you enter the window, and re-browse if it changes (with the usual dialog about any edits in progress). 2. At the same time, we would also check consistency of system and class organizations, and re-browse (thus recreating the lists) if these change.
If you are patient, I'm sure we'll fix this, but I'm equally sure that it won't happen within the month.
- Dan
Dan, A simple solution is to add an Update All option to the Category View. Update all simply looks for through the activeControllers for any open Browser and issues an update. This is not automatic but very simple. Alternately, intercept accept and issue an update to all open Browsers. (If you use the latter, have a class instance variable that will toggle the automatic option on(true) or off. Phil Weichert
Aside from the update stuff others have mentioned, I suggest that part of the problem is that lists are relying upon _indices_ rather than _names_ to access their contents. Thus a list on the SystemOrganization which feels happily secure in considering item 42 to be selected will be very disconcerted when a new category is added in some other browser. Suddenly, item 42 is not where it's at, the class list is now seriously discombobulated and all is sadness.
If, however, the category list were keyed by category _name_, and considered 'System FooBar' the selection, then adding a new category would cause no problem. This is pretty much how it worked in ST80v2.3+ etc.
tim
squeak-dev@lists.squeakfoundation.org
-
Dan Ingalls -
Phil Weichert -
sqrmax＠cvtci.com.ar -
Tim Rowledge