On Feb 18, 2007, at 11:31 AM, David Röthlisberger wrote:


> I write this message out of two reasons: First, I would like to  
> know if you have ideas for things that are missing in the current  
> DIE of Squeak, "things", tools, metaphors, ideas that you would  
> like to see implemented. What are your ideas of how an IDE could  
> help you to work more efficiently in your daily work? Where is the  
> current IDE in your way, where is it not good enough, what could be  
> better? What do you miss, what do you need to get a better IDE?
>

Using OmniBrowser for the last few years has made me notice something  
interesting. I did a lot of work in VW, and came to depend heavily on  
the power of the RB for getting things done efficiently. On the other  
hand, in Squeak I was using OB, and had to work around the lack of  
refactoring support. What I found is that having the right browsing  
UI can make the high-level operations that the RB provides less  
essential.

Here's a slightly contrived example, but it mirrors the sort of  
situation I've often found myself in with OmniBrowser. Lets say I  
have a class that has coordinate data in it, stored in ivars x and y.  
I want this to be private, so I don't have accessors. Now say I  
decide to convert the internal storage to polar coordinates.

With the RB, I'd probably do something like this:

1 apply the 'abstract variable' refactoring to create accessors and  
convert all direct accesses to messages
2 create instance variables r and t and reimplement the accessors in  
terms of r and t
3 remove the instance variables x and y
4 browse the senders of #x and #y and modify them to use r and t  
directly
5 remove the accessors for x and y

That "abstract variable" refactoring is really handy, because I can  
keep the class functional the whole time (particular handy if I'm  
developing using tests). On the other hand, I have to bounce around  
in the browser a lot, and I'll probably have to have several  
"senders" browsers open at once.

Now, in OmniBrowser I don't have that refactoring, but I do have a  
"chase variables" browser. It shows me a list of variables, the  
methods that access them, their senders, the senders of the senders  
and so on. So what I'd do is this:

1 create instance variables r and t
2 look at all the writers of x and y and modify them to write to r  
and t as well.
3 look at all the readers of x and y and modify them to read from r  
and t instead
4 make the writers of x and y write only to r and t
5 remove x and y

What's nice about the "chase variables" browser is that it makes step  
3 pretty easy, because removing the uses of x and y usually also  
involves modifying the senders of those methods and maybe their  
senders as well. The "chase variables" browser shows me the  
transitive closure of the methods that use a given variable. This  
means I can see in a very visual way what I have to do, and what I've  
already done. I'm shifting methods from using x and y to using r and  
t, and the browser shows me a pretty direct reflection of that.

The upshot is that I don't miss the "abstract instance variable"  
refactoring much. Having it wouldn't hurt, and I do want to implement  
it, now that Lukas has got the ball rolling. But changing the way we  
can view code is even more powerful, and opens the door to more  
powerful tools. For example, refactorings are great, but they're  
limited in that they have to preserve the semantics of the code. If  
we could easily see what the effects of a particular change were,  
would it be safe to use powerful tools that didn't preserve semantics?

Colin