Generalized Object Modules Design

Stephan B. Wessels swessels at one.net
Sun Mar 17 18:16:41 UTC 2002


On 3/7/02 3:48 AM, "Bert Freudenberg" <bert at isg.cs.uni-magdeburg.de> wrote:

> On Wed, 6 Mar 2002, Lex Spoon wrote:
> 
>> Suppose I have the following changesets in my image:
>> 
>> URL
>> HTML-Tokenizer
>> HTML-Parser
>> HTML-Formatter
>> 
>> I'm mainly working on the parser, so the current changeset is
>> HTML-Parser.  However, I stumble across a bug somewhere in my code (I
>> think that has happened once or twice.  Please, bear with me.).  After
>> hitting implementors-of a few times, I'm looking at a blue message list
>> window pointing at Url>>fragment.  Voila, this is it, just change one
>> line of code....
>> 
>> Unfortunately the change will end up in the Parser changeset, even
>> though it belongs in URL.  Why can't the system be set up to put all Url
>> changes into the URL changeset?
> 
> Who says it can't? I used to work with just this type of changeset
> management and it was incredibly useful:
> 
> http://www.heeg.de/AppMan18/userGuide.htm
> 

Pardon me for jumping in here but I recognized this problem.  I wrote a
version of that old Application Manager design for Squeak MVC a few years
ago.  I called it a source set manager.  Here's a snapshot of the source set
browser:
    
http://w3.one.net/~swessels/pages/steve/squeak/images/ssmgrScreenShot.jpg

My approach to solving the problem that Lex described was to assume that:
    1) all changes I made went to my current source set
    2) if the methods modified existed in other source sets they were marked
"dirty"
    3) This was also true for modified classes, preloaders, postloaders or
even other "meta" source set operations.  Make a change in any of those
"objects" and they were marked "dirty".
    4) All dirty objects were shown in BLUE in any list in the system.
Therefore you could use standard Browsers and see blue class names and blue
method names to reflect that those entries were dirty.
    5) The corresponding Source Set names were also blue and so you could
easily go to the source set manager and file-out the first source set.  And
all dirty objects associated with that source set were marked "clean" and
were no longer blue in any lists.

It worked for me just fine back when I used to work strictly in MVC in
Squeak.  When I moved to Morphic I discovered that the highlight colors of
selected items in list panes were already being used so I never tried to
work something out going forward.

The application manager concept (originally out of Carleton University) was
actually a commercial product available for Smalltalk/V for a while.  It was
called AM/ST and was produced by Coopers Lybrand.  Back in 1993 the original
developers all left Coopers Lybrand (sp?) and the product technical rights
were sold to a fellow named "Dr. Eddie Curry".  He then contracted me to
take over the technical development and fixing of the product on a part-time
basis.  So I learned a lot about how this product worked.  I joined Digitalk
in 1994 and had to drop technical support for the product because of
potential conflict-of-interests.  I don't know what ever became of the
product.  Then in a997 I was working with a team of ex-Digitalk developers
on a VisualWorks project.  We were trying to develop remotely using Envy and
ran into a lot of challenges.  So I took my previous experience, and without
resurrecting a single line of code from the original product, wrote a new
version for VisualWorks which we used successfully for developing an
internal project.  When I discovered Squeak in 1997 - 1998 I began to write
an even newer version of the same concept which I called the Source Set
Manager.  The concept was that I "wrappered" all source related objects and
then managed those source wrappers in a source set manager.  I used that
successfully, as I was saying above, for quite a while until I decided to go
work with Morphic projects.

There is a link to that original work available from here:
    http://w3.one.net/~swessels/pages/steve/squeak/index.html

I haven't really paid any attention to the Modules stuff but if this stuff I
wrote a few years ago can help please take a look.

 - Steve




More information about the Squeak-dev mailing list