"David Simmons" <David.Simmons at smallscript.com> wrote:
[SNIP]
> > PS. The Module system in Squeak OTOH feels nice to me - "A module is
> an
> > instance of the class Module and it holds classes and sub-modules
> etc."
> 
> I have been there, and done that. This (use of a <Module> classes
> instances) is the essentially the way things worked in (QKS Smalltalk)
> SmalltalkAgents (both the Mac and Win32 versions). It is the long and
> hard-learned lessons from that experience that led to the current
> SmallScript architecture.
> 
> Modules are not at all the same as an arbitrary package of persisted
> objects. However, they do represent extensible repositories of objects
> supporting certain protocol, which includes methods and therefore
> behavior.
> 
> However, as of this post, I have said enough on this topic. I think the
> Squeak community is just going to have to build it, and go through the
> same lessons. 

We very well might do that. And we may end up with something different
too.
Anyway, all insights are welcome.

> The downside of that is that you will have a legacy problem "if" there
> is eventually a consensus that modules should be a kind of class. 

On the other hand I would guess that most people accustomed to other
languages would feel more at home since the approach taken (sofar) in
Squeak is similar enough to many other languages. :-) That can also be a
plus.

> One of the challenges facing the Squeak community, is that you are
> working in an image based world where modules are source based entities.
> If you decide to move to a world of components, modularized binary
> image-like-entities. And if, in so doing, you want to integrate with
> other component technologies [like many/most other languages support
> today], then I think the non-class approach will begin to show its
> weaknesses.

Hmmm. Not that I intend to drag this out - so you don't need to reply -
but surely there are other languages out there with component models
that doesn't equal class to module? I haven't checked Perl/Python/Ruby
(to name a few) lately but I would guess that they don't.

> What I keep hearing is that "classes" are about "instances" and defining
> the "structure" of an instance. This is a very narrow view of what a
> class declaration/definition means. 
> 
> The most important aspect of which is that classes are collections of
> behavior, which are manifest as a unique "class object" and it's class,
> a "metaclass object". The "instantiation" aspect of a class, is merely
> describing its role as a <Constructor>.
> 
> Whether it is modules, or something else, the flexibility to
> handle/adapt a thing/component to a given purpose is done through
> "behavior" and "state" (objects). By defining "modules" as being
> instances of a single class <Module>, you are effectively saying that
> modules have no differences. 
> 
> I.e., You are saying that there is not, nor will there ever be, a reason
> to view one module's behavior (and therefore by implication its
> structure) as being different from another module.

Well, I am not sure we are saying that. But we are saying that they do
have a few things in common otherwise it would just fall apart. There
should be some rules - some decisions made, we need something to rely
on. Otherwise the question "What is a module?" will become totally
impossible to answer and chaos would rule... :-)

So we have chosen a hierarchical namespace. We have decided that a
module is a namespace. We have decided that a module has references to
external modules.

> Alternatively, you are saying that you expect that modules will have
> differences. That there might be different types of modules (projects,
> libraries, components, patches, etc). You might be assuming that a given
> module may require unique pre-requisite/pre-load services,
> initialization upon loading, schema migration customization of behavior,
> or pre-release and finalization mechanisms. 
> 
> However, from the sounds of it, if my second case assertions are
> correct, you are willing to make something more complicated by
> constructing wrapper mechanisms to delegate from the <Module> instance
> to a "well-known" mechanism (like a class within the module) to handle
> it. Where, at that point, it starts to become clear that things would
> have been simpler and more unified if the module had been a class in the
> first place. 

Perhaps. But on the other hand we can all rely on some stable rules of
what a module IS and what it can DO.
Perhaps we want the Modules classes and friends to stabilize, be rather
simple and not deal with some of the things you mentioned. I can see
some value in that too.

> Because then there would have been no need to built the extra/redundant
> module specific infrastructure since module facilities could have
> leveraged/shared the services for supporting classes. Given a unified

I am not sure that the "infrastructure for classes" share much of the
"infrastructure for modules".
I still maintain that they are pretty different beasts. But of course,
my experience in this field is much less than yours.
On the other hand - that may also hold true for most Squeakers, perhaps
we aim for something simpler.

[SNIP of interesting historical view]
> I was trying to help shorten the learning curve by suggesting what
> should be avoided. I was hoping that it might lead, down the road, to a
> more unified view of Smalltalk as a language. On the other hand, if you
> had told me these things some ten years ago when I was first exploring
> these issues I almost certainly would have viewed them very differently
> than I do today.

We will certainly reflect some more on this. I would especially like to
hear more from Les since he also has a lot of experience in this.

Thanks for your clarifications, regards Göran

PS. Smallscript sounds very cool. Will it be Win32 only or are you also
considering other platforms? DS