> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org [mailto:squeak-dev-
> admin at lists.squeakfoundation.org] On Behalf Of Les Tyrrell
> Sent: Sunday, February 24, 2002 11:08 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: Sunday, February 24, 2002 7:46 AM
> Subject: RE: Modules and class... [ a off-topic question ?]
> 
> > It is not particularly
> > hard to envision using the instances to hold different cached
versions
> > of the module; where the instances are the database/repository
model.
> 
> Then I guess we shall continue to disagree.  I've been doing similar
> things in Oasis for years without once ever feeling that my modules
should
> have been classes.  The really difficult problems that have cropped up
> have never been related to this issue, not even remotely.  So, for now
I
> reserve the right to remain extremely skeptical of your claim that
this is
> what they should be.

I agree. 

I find this whole business of focusing on classes as being only for
instantiation, to be a complete red-herring issue, w.r.t. modules being
a kind of class.

I don't instantiate instances of modules to provide repositories. And,
while I said before that I can envision where it might be an important
mechanism for providing versioning and transactions, it is not the
important reason for making modules a kind of class.

My point here is that it is not me who latched on to this issue of
"instantiation" of module instances as being important. 

What are some important things, are:

That modules need custom behavior.

That modules (in the role of) as units of packaging and deployment is a
notion that needs to remain distinct from namespaces. 

While it is also the case that in many circumstances it is desirable for
a module entity to also be able to serve in the role of a namespace.  

And classes are namespaces in classic Smalltalk. The question is, why
have yet another type of namespace. It is totally unnecessary and
creates complexity.

Now, when you start to explore issues of security, packaging, and
versioning, you really want to keep things simple.

It is a very hard problem to provide all the services that SmallScript
offers. I have done it in a very simple and uniform model. Most other
languages are lacking one or another feature I have provided. You can
ignore my approach, you will not make it simpler even if you do, but you
are likely to preclude some of the capabilities that the SmallScript
(AOS Platform) facilities provide.  The SmallScript module system
approach has not "added" anything. It has merely provided some
additional protocols (roles) and state (ownership) for existing things.

In providing a good module design, you want to minimize the number of
elements that you deal with. A module system will already have to deal
with classes/methods and identifying them uniquely through versioning,
strong-names, etc. There is a clear need to process pre-requisites and
schema migration issues during the modular binding and unloading.

Are these the kind of issues you've dealt with?

-- Dave S. [SmallScript Corp]

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

> 
> - les
> 
>