> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org [mailto:squeak-dev-
> admin at lists.squeakfoundation.org] On Behalf Of Ned Konz
> Sent: Friday, February 22, 2002 12:55 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: Modules and class... [ a off-topic question ?]
> 
> On Friday 22 February 2002 02:32 pm, rallende at harlan.di.unc.edu.ar
wrote:
> 
> > Sorry... but we did not use uml. For us a module is a "well defined
> > component of a software system, (and) we may view a module as a
provider
> > of a computational resource of services" Carlo Ghezzi et.al.
Software
> > engineering principles.
> 
> Regardless of whether or not you used UML, my prior comments still
stand
> w/r/t the nature of a module: it needs to be big enough (possibly many
> classes) to do all of the work required of it, and to present a
usable,
> consistent interface.
> 
> Often (most of the time) a single class does not have the capability
> required
> of a module.
> 
> A single class is rarely (re)usable by itself.

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

	Class name: SomeClassWithinTheFooModule
		...
	{
		Function [...class-method...]
		Method [...instance-method...]
	}

	Enum {
		...const declarations for the module
               any class can have enum decls or
               for that matter, arbitrary typed
               properties...
	}

	"" Interface name: ...
	"" is the same as "Class name: ... extends: Interface"
	Interface name: SomeInterfaceClassWithinTheFooModule
	{
		...
	}

      Class ref-name: SomeForeignClass
	{
		Method [
		blahBlah
			...a method on a foreign class which is
                     owned by this module...
	}

In our example, all the elements are "owned" (belong to) the <Foo>
module. And, because we declared it via "default-scope: public", they
are scoped to the root level namespace for declaration and selector
binding. 

We could have chosen to not declare it and left them scoped to the
module itself, or we could have explicitly stated some other
default-scope.

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.

We could produce a CodeFragment/DLL/so from our module definition. Where
that binary-module-file would contain all the necessary compositional
pre-requisites to support on-demand versioned loading of any other
required modules.

-- Dave S. [www.smallscript.org]

> 
> --
> Ned Konz
> currently: Stanwood, WA
> email:     ned at bike-nomad.com
> homepage:  http://bike-nomad.com