Refactoring Browser maintenance (also relevant for other projects)

danielv at netvision.net.il danielv at netvision.net.il
Sat May 18 09:00:00 UTC 2002


It's pretty simple. Right now, anyone that wants the RB can apply a
documented patch and use it. When 3.3 is stable and the frequently used
version, it'll be a matter of a few days of work before anyone can load
it.

So the RB will become either more active now, or simply unavailable.

What does it take to maintain the RB?
* Someone that knows the framework enough to see where to fix things.
* Someone handy with Morphic to expand/fix the various dialogs (examples
- Lint was broken lately by some tiny GUI change. We need to get
code-menus to stop deselecting the text, so that extract method can be
invoked by mouse. A dialog is missing for one of the refactorings...).
* A serious tester to check releases well enough that we know when they
really work.
* Someone to refactor the current release format into small separable
modules, so people can load just the Parser.

Is anyone interested in doing any of the above? if you think the answer
might be yes, reply either on/off list, and include your reservations.

On a few of the topics I raised before -

I've seen a bit of working with modules lately. The GUI is missing, but
the classes are pretty powerful. This means that once the RB works on
3.3a, splitting it up into finer grain modules will be pretty easy. We'd
even have the RB to help do the refactorings...

About DeltaModules, it's simple. The RB adds an instance variable to
Exception. DM's don't like that yet. We can wait until it's fixed (I
think that's one of the things Henrik sees as details he expects someone
else to pick up, so it might be a while). Or we can probably work around
this in various ways.

Daniel

"Andrew P. Black" <black at cse.ogi.edu> wrote:
> I have just tried to use the refactoring browser ... got a walkback 
> that I couldn't understand ... went to my email archives to see if 
> there is a newer version ... read the discussion between DanielV and 
> Stéphane about the right way to maintain it ... and am left feeling 
> rather unhappy.
> 
> As I understand it, the current state is that the "official" 
> distrbution is known not to work, but that
> 
> Daniel is right, I think, that the RB is too complex just to be 
> treated as a goodie and left to take care of itself.  Last fall 
> Nathaniel and myself spent about three days trying (and failing) to 
> track down what we thought would be a simple bug in the abstract 
> instance variable refactoring -- and Nathaniel is really good at this 
> stuff!  In the end, he decided that it was simpler to start from the 
> parser in the compiler to implement this particular refactoring than 
> to track down the bug.
> 
> For those who have not looked at RB, there are two main parts, in 
> addition to the UI:  a parser that matches patterns like '`@method: 
> `@Args ^super `@method: `@Args' and a set of definitions of the 
> various refactorings in terms of the parser patterns.  So, when 
> something does not work in the expected way, it is hard for the 
> uninitiated tell which part is going wrong, and therefor which part 
> to fix; "fixing" the wrong part would indeed rapidly lead to code rot.
> 
> So I agree with Daniel's posting: RB needs someone who understands 
> the framework to coordinate the process of debugging it and 
> maintaining it.
> 
> The reason that I'm unhappy is that no one has stepped forward.  We 
> all have our real work to do, I suppose.   And yet: here is a GOOD 
> IDEA (refactoring) that has been invented by the Smalltalk community 
> and from which all of our code would benefit ...
> 
> What can be done?  I think that making RB depend on stable 
> DeltaModules might be Error 33...
> 
> 	Andrew



More information about the Squeak-dev mailing list