[ENH][Modules] Projects vs Modules, was: Delta Modules

Henrik Gedenryd Henrik.Gedenryd at lucs.lu.se
Fri Oct 26 13:58:14 UTC 2001

goran.hultgren at bluefish.se wrote:

> Projects vs Modules
> ----------------------
> I have read the stuff on the Swiki and my naive view is this:
> A Module is a published piece of code.

Right, an abstract (piece of a) program with no reference whatsoever to how
it is represented, run, or anything. Effectively a sort-of-mathematical

> It is not a "binary deliverable".
> But you can download/load/activate them in your environment. I think it
> is good that they are not binary and I think it would be much harder to
> build such a system with the functionality that Henrik have put in there
> if they were binary. Being non binary also makes it possible to
> manipulate these things more easily. On the other hand the repository is
> a pluggable component so that we can have different kinds of
> repositorys. For example, we could have a repository implementation that
> uses ImageSegments or something to increase loading speed.

> A Project is more of a published binary deliverable. It surely can/could
> contain one or more modules but it also contains live instances etc. It
> is in my eyes analogous to the "binary download" you see everywhere on
> the Internet - just click and go. Typically not used by developers when
> they need a module to use in their own project but more for Squeak
> endusers "surfing for content".

I would like to distinguish Projects from Components--a Component is a
concrete representation of the code in a Module, that can be dynamically
loaded and unloaded. (Components also imply dynamic hook-up and such, which
is a much smaller problem in Smalltalk than in e.g. C++, which has no
standard representation for program meta-objects. Smalltalk already has
all/most of that.) So a Component = a Module or Modules as concretely
represented in Squeak (class and compiledmethod objects, etc.).

A Project is more than just this.

> A Project is more of a published binary deliverable. It surely can/could
> contain one or more modules but it also contains live instances etc.

I assume what you read was <http://minnow.cc.gatech.edu/squeak/2058>.

Importantly, Projects have contents, as in "content provider", not just code
(but it may contain code). This is what you call live instances, and I think
this is the essential difference between Projects and Components.

What projects really are today is kind of vague, but the best notion I've
been able to come up with is "the kind of thing Alan wants kids to create
with their DynaBooks". But Alan/SqC also seems to have frequently changed
their mind about^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H refined the notion of what
Projects are.

I proposed Creation as the best name I could come up with instead of
Project, which is extraordinarily vague and generic for such a specific use,
and gives poor hints to what this "thing" is and does. A Creation is a
collection of "hand-made" objects that someone has created (with a nod to
Koestler with the colored planes). See the above page for a discussion of

As I see it, as concepts, Components are layered on top of/incorporate
Modules, and Creations extend Components to include hand-made objects.

a Creation   (     )
Components   (     ) *      (0 or more)
Module(s)    (     ) +      (1 or more)

> Example:
> I write a cool Morphic game including classes for general animation. The
> code is composed of a Module representing the Game itself with 2 more
> general submodules for Animation and Sound. They are not really blessed
> to go into the "base image" so I put everything in "People/gh/CoolGame".
> Ok, I upload it all onto the virtual module server (more on that later)
> so that people easily can load this module.

Yes, this is enough if all your objects can be programmatically generated by
your code.

> But I also set up a Project where I start the Game up with a centered
> window and I also type in a todo-list in an open Workspace. Finally I
> smack in a nice looking background image and then publish the Project
> onto Bobs superswiki AND also to another superswiki in Sweden containing
> only Morphic games (just fantasy).

These are "hand-made" (ie. non-programmatically generated) objects, which
code isn't sufficient for creating (without taking extreme measures). At
least code isn't convenient for creating them. You need the ability to
conveniently (distribute and) load _objects_. This is the added role I
assign to Creations. I think Creation also implies this having to do with
"hand-made" objects (vs. code-generated).

> So, developers typically load the module to get to the code and perhaps
> reuse my Animation module or just check out how the game was done.

Right, just to get the code, Modules are enough. Components/image segments
may be convenient (think the 1MB refactoring browser).

> End
> users typically find the project and loads that - it probably is faster
> and they get a "just point and click" experience. They get the modules
> with the project, but that is just a bonus.

Right, this to get the non-code objects too.

In general, I think Repositories should be a general facility for
conveniently storing and accessing anything Squeak-related, including e.g.
Projects/Creations, so that you can just give a path to a Project, or help
pages, or you personal preferences file, or whatever, and Squeak will be
able to locate the files for you.

> regards, Göran

So what we really need is for SqC to agree with this ;-)


More information about the Squeak-dev mailing list