So James Robertsonpulled off a post with a graphic of a different sort of method view that is currently running 22+ comments. I had agreed last night to post some thoughts about it.

When James asked me what I thought, my initial reaction was "what problem are you trying to solve?" It remains my question. I think you have to consider that to decide if it is really of any value, not just a "wow, that looks like something that made me feel comfy once upon a time in an unnamed context." I'll list 3 refined areas where I can see this being something that might be tempting. There are probably more, I'm sure. But three's a good number. If you're incensed about an obvious omission, you can blog about it too.

Comparative Browsing

One reason for seeing multiple methods printed close together is so that you compare them. This is the case for similar methods. The current browser has something like this. Select two methods and you get a compare tab. The compare tab shows side by side panes with red highlighting between the differences.

Belay the "stuffy defensive smalltalker" accusation for a moment. My purpose is not a sort of "done that already, don't need your mockup." It's to put some more data on the table and talk about it. There are some things I don't like about the above.

• It doesn't do 3 or more well (did you know that if you select 3 though, you can use the menu buttons to change what each pane shows and it will let you pick from all 3?).
• The scroll isn't locked together.
• The visualization of the differences is as basic as it gets, and could be more.
• For all but comparison of similar named methods, it can be nigh impossible to get the two methods you want to compare in the same browser.
• You can't actually accept changes (the menu items there, but it's just to tease you apparently).

When compared to the concept drawing James provided though, I think a refinement of the existing is a better place to start, for this particular problem. In particular, it offers these advantages when the two are compared:

• Side by side layout (rather than over above) for comparison purposes is the more common. Because it works better.
• It has the beginnings of comparison annotation.
• It provides obvious scope boundaries (more on this later)

Cognitive Browsing

Some commenters pointed out that it can be nice to get a number of disimiliar, but related methods together side by side in one concise space. Perhaps an algorithm that spans multiple methods, where seeing them co resident in the same pixel-estate helps comprehension. Let's call it the "light box" problem. Array a number of methods together and study them in whole.

Some have mentioned Whisker. Cool stuff. Showing the methods all together makes good sense. There is still a primary problem of navigation though. It doesn't matter whether you dock/lock windows together, or have a single pane thing, or whatever, the problem is finding and selecting those methods which you want to include in your study.

A good start would be to support drag/drop to such a tool. Grab a method and drag it onto one of these "light box" tools and it's added there. Add some quick easy stuff for bringing it implementors/senders, and removing stuff from it.

If we're going to use said tool for anything other than looking, we have a real problem with the mockup:

Without additional syntax, we have no way of knowing where a method ends and starts. What you delineate because of a bold, unindented method pattern, and a blank line in between, isn't tangible evidence to the compiler of a start and stop method point. We could use subviews subtly to overcome this problem, and thus preserve the clean look of it. Otherwise we might have to do something like put in !!'s. This is the "scope boundaries" issue I referred to above.

We also have no way of knowing which snippet belongs to what class. Do we annotate that information on there as well? Maybe it's obvious in this case where we're continuing to use the top part of the browser as a navigation tool. That's good because it's a nice reusable component, bad because it will limit the kinds of things we can put on the light box at the same time.

And I repeat, it is not my intent to be defensive/stuffy about these. I think these are good problems to consider how to improve. I'm just trying to put some concrete thoughts down on paper about the issues involved.

File Browsing Mode

In our third scenario, we explore the idea of making Smalltalk more Eclipse like, more Visual Studio like, more XCode like. These systems all work with a set of files, which are usually bound logically together by being in the same directory. Some files have large amounts of code in them, some have small.

My personal experience tells me I have no desire to do this with Smalltalk. One aspect of the problem is that Smalltalk programs (whether they should or not) tend to have more classes and finer methods than their counterparts in these other systems. 500 class Smalltalk systems are no big deal. The VisualWorks base library is 1466 classes and 31508 methods. I could be wrong, but it doesn't seem that a library such as Cocoa has near this amount. I posit that the scale of reification in Smalltalk programs makes these approaches difficult. I don't know for sure. I know that as a program goes up in class/method count in XCode, I start to go crazy.

But I digress, the goal was to explore the idea. If we're interested in working this way, then we start looking at whole classes or packages as single files, all in one text view with a single scroll bar. In this case we definitely have to deal with the "scope boundary" issue. How do you delineate where methods start and stop. And are methods enough, don't you need to show class definitions too? What we might want in this case is an annotated file browser basically. We already have file format for Smalltalk (a couple of them actually). They're designed for storage, not lots of human reading, so they could use some evolution surely. But here's a quick mockup of what something like this might look like in the prototype stage:

This might make Smalltalk more approachable to the uninitiated. It might not.

More to Follow

I had a 180 degree idea that I was going to explore here. I've been pondering it for a while, just idle thoughts. But this subject inspired me to brain burp. Alas, this has grown long, and I have a Pine Wood Derby to attend early in the morning, so it'll have to wait.