> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org [mailto:squeak-dev-
> admin at lists.squeakfoundation.org] On Behalf Of Les Tyrrell
> Sent: Friday, February 22, 2002 9:48 PM
> 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.

It is an illusion. There are no "loose" methods per-se in a module.
Where, "loose" means a method which is not part of a method dictionary.
One certainly can create unbound methods (that's what an eval or an enum
is).

A "function" is just a "class-method". A method or class-method defined
on a foreign class is not considered to be a "loose" method. 

A module is a package (or think JAR/image if that helps) format, where
the first class object for referring to it [and its constituent
elements/resources] is the module's class.

> 
> What I don't see from your example is any further evidence that a
module

Modules have loading and unloading behavior which may need to be
customized. That requires code that belongs in a class.

Modules are repositories. That requires behavior that may be desireable
to customize (or even change on the fly).

Modules are first class entities that need to be referred to from code.
They need to be unambiguously identifiable. They need to be versioned.
They need to have properties and be structurable. They need to contain
namespace visible entities because 90% of the time you want to treat a
module role synonomously with a namespace role (just not 100% of the
time -- so the semantics must be distinct).

Remember that a "module" is a unit of packaging/ownership/deployment.
Remember that a "class" is a "namespace". So a <Module> can serve both
(distinct) roles at the same time via interface/protocol/role behavior
-- which is the key to re-use and unification/simplification.

Classes already provide all this functionality, so it is wrong to
re-invent all this behavior and not re-use class/namespace services. It
is right to specialize a class by providing additional
"role/interface/protocol" to support module services.

> 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.  

A Class does not always instantiate instances, but its metaclass does
always instantiate an instance -- the class object. 

Thus, classes are objects unto themselves with unique behavior and
characteristics. I.e., a class declaration defines both the structure
and implementation of "instances" and the "class" itself.

> I never envisioned a module doing any of these things- 

Ok. However, just because you did not envision things a module might or
might not do, does not mean someone else (like me) would not envision
good reasons to do some of these things. With modules as classes, your
vision, or my vision is not a limiting factor for other people's vision.


It also keeps that system simple and unified. We are not creating yet
another first-class entity type.  Ideas for developers are simpler and
unified because one only needs to learn about classes [not modules,
namespaces, etc as all being unrelated things with different mechanisms
that are confusing and require different schemes to access, etc].

> 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.

That is a very narrow view of what a class is. And, as I said, it
entirely misses the point that a class declaration also describes the
"class" object itself. Have you thought about how a repository might be
managed. What a external DLL might look like in this situation?

It does not pay to be shortsighted here, by presuming it would never
make sense for a module class to create instances. This is like the
shortsighted Java design for interfaces (that assumes you would never
want to instantiate one) -- a rule that flys completely in the face of
both re-use and good design -- and which has manifested itself with Java
having a number of broken elements w.r.t. interface method binding and
implementation sharing. Or like Java's inner-classes vs
closures/continuations, or like Java's collection/iterator mess due to
lack of ad-hoc polymorphism (generics), or like numerous problems in
Java's numerics system due to lack of multi-precision arithmetic and
real "value" types and methods, etc.

> 
> > 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.

One role of a module is to behave as a database/repository. Which also
means that it might act as a modularized image. These need to be
versioned. Again, there is a lot more "unification" that is possible.
Being shortsighted is a mistake.

But, even if none of those things were true, why invent yet another
"entity" to have to bind/reference/interact with, when classes already
exist? That is in opposition to smalltalk principles/philosophy. It is
the same reason why the "SystemDictionary" should not exist, and pools
and class-pools should be one and the same thing; and why namespaces
should not be a separate entity type that is distinct from classes.

Where the goal is to keep things to their simplest form but no simpler,
unify principles/mechanisms wherever possible. This means minimizing the
number of required (distinct) elements where possible, rather than
increasing the number of different elements. 

Only introduce new elements when existing elements cannot serve the
need/requirement adequately.

-- Dave S. [SmallScript Corp]

SmallScript for the AOS & .NET Platforms
David.Simmons at SmallScript.com | http://www.smallscript.org

> 
> - les
>