This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Sharing Smalltalk Extensions
Feed Title: Richard Demers Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rademers-rss.xml
Feed Description: Richard Demers on Smalltalk
Smalltalkers love to share their goodies. The Cincom VisualWorks Public Store has become the the most important mechanism we use to share all kinds of really cool stuff. We also use e-mail lists and blogs, but they lack the permanence and searchability that we really need. The Public Store is not without its problems in regards to finding things, but that is now being addressed by Cincom engineers. In any case, that is not what I want to write about in this note. Instead, I want to address a deeper problem that I believe can be solved with the judicious use of the Public Store; namely the problem of sharing extensions to Smalltalk classes.
Anyone with a modicum of Smalltalk experience delegates function to the class that owns the problem. For example, if you need to manipulate a string in a special way for the "Doit" class you are writing, you don't add a new method to Doit, you add it to String -- with an instance of String as the message receiver. Actually, you add it as an extension to class String in a package of your project. That way, it also becomes part of your application that you can keep track of, and it doesn't clutter up the base language packages.
A common practice is to go one step further, and create a separate package for the extensions of a project -- and sometimes for all the extensions of an enterprise. Great, but now we see myriads of such extension packages, many of which are in the Public Store, each effectively hidden away from public view and sharing.
Wouldn't it be better if there were a single Public Extensions package in the Public Store? One that we could all contribute to and download at will? One that we could look in when we need a method not in the base language?
Sounds good, but what are the issues?
Scope.
Initially, this should be limited to Smalltalk extensions that run in VisualWorks, though they may have been developed in other Smalltalk IDE's.
Similar ideas to this could be applied to classes and frameworks, but that is beyond the scope of this proposal. One step at a time, please.
Quality control.
This is a big one, but easily solved by requiring that every submitted extension be accompanied by SUnit TestCases to be put in an accompanying package.
Any programming problem can be solved in multiple ways. Clearly we would want the best methods possible. This is somewhat subjective, but it is not too hard to judge if a method is written in an intention-revealing, literate style, if it uses an efficient algorithm, if it is adequately documented, if it "fits in" with the other methods of the class being extended, etc.
Organization
This is clearly an open-ended problem in that any class in any package, no matter how application-specific or obscure, can be extended. Initially, we should limit this to just the Base Smalltalk classes.
The Base Smalltalk classes are themselves in many packages, so it would be a good idea to have a Public Extensions bundle that contains corresponding Public XXX Extensions packages.
Many extensions affect only one class, but others affect many classes that are related in some framework. For these, it would be useful to put all the related extensions into separate Public XXX Framework Extensions packages
Submissions
The process of publishing an extension is simple enough: download or create the extension package, add the new extension to the package, and publish the package.
Occasionally, someone will have to republish the extensions bundle with the latest versions of all the extension packages.
We can use the "blessing level" and the comment area of the bundle and packages to inform each other what is happening.
Getting started.
If I get some level of agreement with this proposal, I'll create the initial bundle and packages.
After that, it will have to be a public, "open source" project to mine our existing packages for candidate extensions -- in both the Public Store and in private repositories.
Previous Topic
