-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev- admin@lists.squeakfoundation.org] On Behalf Of Les Tyrrell Sent: Friday, February 01, 2002 4:09 PM To: squeak-dev@lists.squeakfoundation.org Subject: Re: Namespace and Module Discussion
----- Original Message ----- From: David Simmons David.Simmons@smallscript.com To: squeak-dev@lists.squeakfoundation.org Cc: 'Dan Ingalls' Dan@SqueakLand.org; 'Doug Way'
'scott' scott@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@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