Namespace and Module Discussion

David Simmons David.Simmons at smallscript.com
Sat Feb 2 22:23:37 UTC 2002


> -----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 01, 2002 4:09 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: Namespace and Module Discussion
> 
> 
> ----- Original Message -----
> From: David Simmons <David.Simmons at smallscript.com>
> To: <squeak-dev at lists.squeakfoundation.org>
> Cc: 'Dan Ingalls' <Dan at SqueakLand.org>; 'Doug Way'
<dway at riskmetrics.com>;
> 'scott' <scott at SqueakLand.org>
> Sent: Friday, February 01, 2002 2:42 AM
> Subject: Namespace and Module Discussion
> 
> 
> > Hi All,
> >
> > Is it too late to have a hearty discussion here on the squeak
discussion
> > group regarding namespaces and modules?
> > I.e., have the plans for squeak been cast in stone. I've briefly
read
> > some of the module and namespace discussions on the Wiki.
> > If not then I would like to try and participate in a discussion on
this
> > area with the goal being to strive for some level of compatibility
with
> > existing Smalltalk implementations of namespaces, modules, etc...
> 
> I think that this would be a worthwhile discussion, since it would be
> rather nice for there to exist a fair degree of inter-operability
among
> the various Smalltalk dialects.  Currently, namespaces and modules are
> evolving separately in each dialect.  In the long term, this could be
a
> problem for the overall health of the Smalltalk community.  In the
short
> term, this gives us different approaches with varying strengths and
> weaknesses, and in that sense could prove to be a good thing as we see
how
> well each works in practice.

In that vein, let me sally forth with a few comments:

For a variety of reasons (presumably to be uncovered in subsequent
posts) the following rules hold in SmallScript:

a) Classes [class/metaclass pair as a unit] are binding-scopes
(namespaces); most frequently referred to as "scope(s)". The class pool
holds the variables.

b) Types for FFI and the optional type system, are classes. This implies
lots of things... Not the least of which is that you can write the FFI
marshalling code as methods within the class.

c) Modules are classes. Which implies a lot of things... Not the least
of which is that modules can have unique behavior, and offer runtime
scoping as a separate aspect/notion available within single unified
object's capabilities.

d) Interfaces are classes. Lots to say here, but that would be a
tangential discussion.

e) All runtime-binding-scoped elements are "owned" by one (and only one)
module.

f) Modules are units of packaging/deployment. A "module" partitions
deployment/loading of resources (including classes and methods). A
"module" represents a "unit of packaging/deployment" for
structuring/organizing availability of resources (including classes and
methods).

g) A "scope" is a "unit of priviledge" which partitions runtime binding
of variables and behavior. a "scope" [sometimes referred to as a
namespace, but best referred to as a binding-scope] represents a "unit
of priviledge" for runtime access-permission to "something within that
scope".

h) Modules are assembled (packaged) as COFF/ELF/CodeFragment files by
default [this offers innumerable benefits]. Where a COFF/ELF file may
contain 0 or more modules. A pure module with no resources or externally
compiled C/C++/Asm code is a self describing blob (and so can be
packaged in any form desired). Any resources or and methods exported as
callback entry points, are exposed directly through standard OS platform
COFF/ELF/CodeFragment facilities.

i) Scoped methods (via selector namespaces) enable partitioning
(scoping) of code changes within a given class. Remembering that by rule
(e), all methods are owned by one, and only one, module.

j) Symbols are scoped. Every symbol consists of a common selector name,
and a scope (as defined in (a)).

Given the above rules a system can be automatically sliced and diced
into discrete shared-libraries (modules). Where a shared library can be
loaded or unloaded on demand and offers native operating system program
access to resources and exported entry points, digital certificates,
etc. 

The shared-library mechanism is possible because all of the
environment/image changes a module makes are known through the "module"
ownership rule(e). And because the selector-namespace rules for
scoped-methods ensure that changes made to a common class, by different
modules, are distinctly identified by rule(j).

-- Dave S. [SmallScript LLC]

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

> 
> > I would add that this is area where simplicity is truly elegance in
the
> > best sense of Smalltalk's philosophy. But it is equally an area
where
> > recognizing synergies and making the right steps for achieving
> > simplicity can be a hard thing to get right.
> 
> I whole-heartedly agree with you on this point.  It remains to be seen
how
> this experiment will turn out in Squeak, but it is underway
nonetheless.
> 
> - les
> 
> 





More information about the Squeak-dev mailing list