Modules instead of Behaviors (was: Generalized Object Modules Design)

Anthony Hannan ajh18 at cornell.edu
Wed Mar 6 06:16:10 UTC 2002


Hannes Hirzel <hirzel at spw.unizh.ch> wrote:
> On Tue, 5 Mar 2002, Anthony Hannan wrote:
> > 	A module is a group of related methods from many classes that fullfill
> > a single functionality.  A module is equivalent to a method category
> > like 'printing' which may cross many classes.  All methods in 'printing'
> > from all classes would end up in a single module called 'Printing'.
> 
> I don't agree.
> I primarily see a module as a collection of classes at the moment; cf. a
> Java package or a class category in UML.

We are thinking of two different definitions for "module".  I was
thinking of a module as an object that implements an interface [JIGSAW]*.
 A class is a type of module, so is a "functionality" which is what I described. 
You, Richard, Henrik, and many others define a module as a loadable
unit, ie a changeset.  To avoid this confusion in the future I will not
use the term module and instead use terms like behavior, functionality,
changeset, layer. or loadable unit.  All of which have been called
modules before but actually have different meaning.  So in my original
post under the "Modules instead of Behaviors" thread please substitute
"functionality" for "module" (including in the subject).

> > 	Note, I do not address loading or maintaining changes to modules in
> > this design, I only address the structure of a module itself after it is
> > loaded.  Changesets/transactions/layers are an orthogonal issue that
> > requires its own design.  Whatever that design turns out to be, it will
> > be used to load and version module objects.  But I think it is important
> > to keep these issues separate.  Modules are not repositories, they are
> > just another meta-object like Class or Behavior, in fact, I am proposing
> > that Module replace Behavior.
> 
> I do not understand this.

I was just trying to say that this design only talks about behaviors and
does not talk about loadable units which I put off as a separate topic.
 
> I think we should keep the direction Henrik is going at the moment and
> later look into the PIE approach Alan Kay recommended.

I think we should consider as many designs as possible as early as
possible, hopefully avoiding some recoding in the future.

> [your design is] an interesting approach but I think it is too far
> reaching in the changes involved at the moment.

We are probably going to be moving to a new VM anyway for block closures
so this is a good time to also introduce behavior changes.

> For me it is not easy to see the benefits.

Please refer to my previous email responding to Richard

> How does the approach you describe relate to the PIE approach?

I punted on layers/loadableUnits saying it is orthogonal to
functionality.  But I do plan on exploring it next.  But in general I do
like the PIE approach.

> ... like Robert Hirschfeld did with aspect oriented 
> programming (Implementation of AspectS)
> http://www-ia.tu-ilmenau.de/~hirsch/Projects/Squeak/AspectS/ 
> Actually your proposal above seems to go into that direction. I'd like to
> recommend you to download Robert's example image and read his
> documentation)

I have.  And "functionality" is very similar in meaning to "aspect". 
But the implementation, using method wrappers, is quite different and I
think is address a different problem.

> ---------------------------------------------------------------------
> P.S. on block closures
> ---------------------------------------------------------------------
> 
> Do you have some information on when we get the block closures 
> in the update stream?

It can't just be put into the update stream because it requires a new
VM.  We have to wait until we are ready to make this major change.  I
think Tim and others are targeting Squeak4.0.

> I'v seen that they are now in the harvester's  table. 
> I read some time ago that block closures need a new VM. Did the VM people
> already implement these changes?

I implemented the VM changes and they are on the BC swiki page.  All VM
changes for block closure are written in Slang/Smalltalk and generated
from the image.  So they won't need to go into the VM code on
sourceforge, they just need to be included in the Squeak4.0 image.

> I'm especially interested in having your cleaned up / refactored 
> Parser classes. Is this compatible with the most recent changes Henrik
> did.

You should just download the BC image and VM and check it out, or even
start using as the BC image as your main Squeak (I do of course).  It
can accept public updates just like the standard one.
Which changes of Henrik's are you talking about?

> And finally - a great thank you for your diligent and intensive work.
> (As a non-mother tongue speaker - I hope I chose the right adjectives;
> to put it in simpler words - I think you did a great job!)

Thank you, Hannes.

Footnote [JIGSAW]:
Gilad Bracha, "The Programming Language Jigsaw: Mixins, Modularity and
Multiple Inheritance", Ph.D. thesis, Dept of Computer Science,
University of Utah, March 1992.
<http://citeseer.nj.nec.com/bracha92programming.html>



More information about the Squeak-dev mailing list