-----Original Message-----
From:	squeak-dev-admin at lists.squeakfoundation.org
[mailto:squeak-dev-admin at lists.squeakfoundation.org] On Behalf Of Les
Tyrrell
Sent:	Saturday, February 23, 2002 12:48 AM
To:	squeak-dev at lists.squeakfoundation.org
Subject:	Re: Modules and class... [ a off-topic question ?]


----- Original Message -----
From: David Simmons <David.Simmons at smallscript.com>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Friday, February 22, 2002 3:31 PM
Subject: RE: Modules and class... [ a off-topic question ?]

> I think the original intention of saying a module should be a class is
> best illustrated by a pseudo-code example (in this case, from
> SmallScript).
>
> Module name: Foo default-scope: public.
> Function ["aka a class-method on the <Foo> (module) class"
> Initialize
> ...configure the module upon loading...
> ]

What I get from your example is that it is useful to be able to attach
methods
to a module, which are not defined in any class.  Basically, similar to
having
a module hang onto a set of blocks that it evaluates under certain
conditions.
Letting these "Module methods" be similar to "Class methods" in some
respects
would, I think, be a good thing.  The same sort of thing would be useful for
regular Smalltalk Pools- ( although Squeak handles Pools differently than
VW,
IIRC ).  In VW pre-5i, Pools had a defining class which had the pool
initialization method as a class method.  Not very graceful- the pool really
needs to do that for itself, since the few true pools that actually exist
 typically only about 5 ) live a life that is somewhat independent of any
one
class.

What I don't see from your example is any further evidence that a module
should *be* a class- classes do many other things, most of which I don't
think
are appropriate for modules- ie, classes instantiate objects, maintain the
template by which the structure of instances is defined, maintains the
methods
by which its instances behave, etc.  I never envisioned a module doing any
of
these things- ie, they do not instantiate, they do not maintain the behavior
of such instances, and they do not describe the structure of those instances
either, since there are *no* such instances.

> What we see is that a module may consist of any set of classes, methods,
> etc. These elements are all owned and packaged with the module. Thus the
> module acts like a mini-image/JAR file for the purposes of deployment
> and modularization of language entities.

There is some similarity in the "packaging" role between classes and
modules,
but again I don't see the resemblence going much further than that, aside
from
what you note above about enabling the module to maintain at least some of
its
own behavior.

- les