[Modules] Components or Modules??

Robert M. Lefkowitz r0ml at optonline.net
Fri Aug 17 03:26:32 UTC 2001


On Thursday, August 16, 2001, at 08:58 PM, Bijan Parsia wrote:

I agree that the image is a good thing.  The pain that I feel when I 
complain about the "lack of modularity" is related to the
ability to UNDO.  If I file in a ChangeSet, and find that it did 
something obnoxious (like redefine Set>>union: -- an actual example) I 
would like to UNDO that     
module/component/experiment/heap-of-code .  People who live in a 
file-based code world -- where the program is link-edited, then run, 
then stops -- have a notion of modularity that is associated with 
"assembling" the code.

But if you live in an image (body-surfing in the object sea), the 
assembly happens rarely.  It is the DIS-ASSEMBLY that's hard.
The solution after a bad exploration winds up being -- start with a 
fresh image, and file all my stuff back in.  Because the
ability to unload modules is so weak.

So I'm arguing that the core functionality -- the definition of a 
Module (and/or component) -- is a unit of Stuff that I can remove.
Currently that means Class  or Category .    But ChangeSet does NOT 
meet this definition of Module.

r0ml

> --On Thursday, August 16, 2001 2:12 PM -0700 Allen Wirfs-Brock 
> <Allen_Wirfs-Brock at Instantiations.com> wrote:
>
>> So what are we trying to accomplish?  Dan listed a set of "desiderata"
>> that I can whole-heartedly support.  However, I would like to step 
>> up one
>> level before plunging into the details.
>>
>> My understanding is that a common goal is the elimination of the all
>> encompassing, monolithic image. I can't argue with that goal and I 
>> don't
>> think I need to reiterate all reasons this is desirable.  However, 
>> there
>> are a lot of different  reasons that different constituencies have for
>> wanting to see this happen.  I don't necessarily believe that one
>> solution will make everybody happy.
> [snipped interesting discussion of a reasonable distinction]
>
> I wish to speak for the all encompassing, monolithic image. It's been 
> pretty good to me, and good to Smalltalk (and similar systems).
>
> Yes yes yes, shrinking is a pain. Etc. etc. etc. I'm with everyone.
>
> But there's something *golden* about having a 4 file install (vm, 
> image, sources, and changes). Wrestingly with VisualWorks packages 
> and paths tends to make me grumpy. Python is way worse. SWI-Prolog 
> (the other system I've been dorking with) is somewhat better, if just 
> because it's less elaborate (at least, my install is).
>
> Anything that sends me scurrying to the filesystem makes me want to 
> HOLLER! (And not in joy :))
>
> I think this is on the side of the "casual hacker" person :) I'm 
> fairly sure all involved are with me, but I feel inclined to make 
> noise about this. The monolithic image has virtues and I'd rather not 
> *lose* them, if at all possible.
>
> Similarly, there's already at least one modularity/polymorphism 
> dynamic going on in the system. (I.e., classes and messages.) (Oh, 
> and projects and changesets and *morphs* and views and... :)) This 
> one is fairly thoroughly integrated with the system and its tools.
>
> Anyway, you get the idea :) I wouldn't mind knowing whether a 
> specific proposal let me end up with the "happy mess" that is the 
> current image *if I want it*. Similarly, I favor solutions that build 
> on the current mechanisms.
>
> Cheers,
> Bijan Parsia.
>
>




More information about the Squeak-dev mailing list