Antony Blakely has been writing about "file based Smalltalk ideas."

I don't have much substantitive to the specific points he's talking about. But it did bring back a cool memory once again. I shared it with a number of people at ESUG.

At Camp Smalltalk in Colorado (2004?), Claus Gittinger was there, playing with Smalltalk/X. And one of the things he did was built an interface to what was at the time, I believe, called UFS? Nowdays, I think it's called FUSE. The point of this library, is that you link it to your program, and define some responds to queries. Your program can now export what appears to be a filesystem which can be mounted by the OS. And you can then decide how your application might represent it's data as a filesystem.

Claus did just that, and it was really cool. Basically, the smalltalk "image" showed up as the root of the mount point. Under that were directories, one per class. And he had a simple mapping scheme. There was a special file that showed the class definition. I don't recall how super/subclass relationships were expressed. Possibly as directory structures. The fun thing though, was that each method was a file. The name of the file was the method name. And the body was in the file. When you edited one with vi/emacs, and saved it, that invoked the compiler in the image and updated the method. Same for class changes. We could grep for expressions in the "image" using normal tools. We used sed/awk to rewrite a method or two. find to find classes and methods.

I have over the years thought about this and a desire to see a "conventional" source code control system interfaced with Smalltalk. One conclusion I came to after that, was that this fine grained file mapping would be the way to go if feasible. The other is how valuable SVN would be over CVS. One thing that SVN adds to the CVS equation, is a good model for moving/renaming, something CVS was not able to do. But Smalltalk development is often about lots of renaming stuff. And being able to properly model and track that has always seemed important. The concern I have with mapping at this fine grained level, is that a well stocked image might have around 100000 methods in it. That's at least 100000 leaf files. And I'm not sure how well SVN would scale to that kind of scenario.