Modules and class... [ a off-topic question ?]

David Simmons David.Simmons at smallscript.com
Tue Feb 26 20:43:12 UTC 2002


Ok. Maybe we can start from a different perspective.

Let's try to identify and discuss the characteristics of modules, in a
somewhat ad-hoc fashion.

Let's begin identifying two different contexts in which a module will be
a manifest thing. 

a) There is the view of a module from inside a running environment where
it is seen as an object.

b) There is its binary/source packaged form as exposed/distributed to
the outside world. Where it is useful to begin with the assumption it
can exist as a self-describing BLOB for storage/archival in any form.
Pragmatically the outside world already provides a number of standards
for libraries of program language data and executables. 

Therefore, in all likelihood, one of the formats for our BLOB will be a
file. In addition, it would be valuable if that file conformed to
standards employed in other languages and operating systems. So making
it a COFF/ELF/CodeFragment file could be quite beneficial.

All right, let us leave that thought for the moment. There are still
many things to explore in both (a) and (b). 
=====

Let's move to inside the environment. We'll begin asking the question,
what does it mean to "modularize"? How might modularization be made
manifest?

To answer some of that question we have to make some statements about
the role a module might play. So, let's start with its role as a unit of
packaging and deployment.

Given the importance and value of interactive development, imperative
evolution of an image, and the need to organize the result, I begin with
an important assertion.

Each "primary" module-packageable elements is "owned" by one, and only
one, entity. This is a key idea because it allows us to unambiguously
partition the structural (language) elements of an image into distinct
parts (modules).

Examples of "primary" module elements are:

    - behavior (class/metaclass/etc)
    - method
    - pool-variable (shared-field)

Remember, a class is our namespace mechanism. A module is a class. We
therefore can keep the number of "primary" elements we need to work with
and know about, to a minimum. It also worth remembering/thinking-about
literals and other "language" elements (and how they are managed) as you
ponder these ideas. I.e., we are trying to distinguish the elements of
the "language" from the secondary/derivative elements that are artifacts
composed from those "language" elements.

Furthermore, I can efficiently scan the system and identify all elements
that belong to a given entity. We can always ask a given "primary"
module-packageable object what module-entity it belongs to?

I need to jump ahead a bit here (I have limited time to make these
posts). What we will recognize is that while it is valuable to be able
to package any kind of object, a module-package is different from an
arbitrary (package) collection of objects. It has more specific
definitions and protocol regarding the elements it knows and
understands.

This is a key idea. A module BLOB format only supports a specified set
of primary (language-element) object types. Noting that since we have
meta-object protocol, and since we can define one of those types to be
an arbitrary object package, we can provide support for a module to
contain any type of object. 

Said another way, using a well known object we'll call a "package", we
can embed arbitrary objects into a "module", by placing them inside a
"package". By doing so, we can regularize the structure and form of
module. 

We can think of a package as just another "resource" that a module owns.
It is up to the module (or its well-known content types) to decide how
and when it will access the "resources" it contains. 

In my work, I distinguish "module" from "package" for this very reason.

Here are some examples of well-known types for a module.

1. String (and string-literal)
2. Symbol
3. GUID
4. Behavior
5. PoolVariable (shared-fields)
6. Method
7. ArrayConst
...etc...

===============

I'll stop here and wait for comments and questions.


-- Dave S. [SmallScript Corp]

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


> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org [mailto:squeak-dev-
> admin at lists.squeakfoundation.org] On Behalf Of
goran.hultgren at bluefish.se
> Sent: Tuesday, February 26, 2002 2:21 AM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: RE: Modules and class... [ a off-topic question ?]
> 
> "David Simmons" <David.Simmons at smallscript.com> wrote:
> [SNIP]
> > I think that it is mostly lack of experience in this space that is
doing
> > the talking here amongst Squeak folks. Consider what happens when
you
> 
> It may very well be. On the other hand we do have some experienced
guys
> too! :-)
> Like Les for example. So I don't think that is the only reason for our
> reactions to your view.
> 
> Nevertheless I find your view very interesting and I am arguing
because
> I want to understand it better. And I do, as many others have
testified,
> very much value your input here - be sure of that.
> 
> > need to define a new type of module. How will you package and deploy
it
> > when nothing will understand it in base systems. It is very likely
to
> > result in some kind of non-OO kludge mechanism...
> 
> Ok, so your argument being that if a "module" can be defined using the
> same freedom as we define classes AND we also make sure our
architecture
> for modules handles all that freedom then there will be much less
limits
> to what future module "types" can be/do.
> 
> Ok, I see what you mean. But... is it practical to give modules that
> much freedom? And just being a dumb average Smalltalker here: How do
you
> compose your modules in Smallscript? How does a class "contain" other
> classes? Just curious - I could of course download and dissect but I
> have no time right now.
> 
> > > But clearly, from David's examples, Smallscript is *not* a pure OO
> > > environment. Smallscript looks very cannibalized.
> > > Functions vs. methods vs.
> >
> > There is no versus. It sounds like you've not really understand what
> > classes are and how the MOP and behavior facilities support objects
and
> > messaging. And, as a result, you do not understand the mechanisms by
> > which functions can be unified with an OO architecture. A function
*is*
> > a class-method.
> 
> Well. Trying to define "function" is kindof tricky. I always think of
> "functions" as having no state.
> On the other hand you could just view any state it does have access to
> as "parameters" and then, voila (hmmm, how do I get accents in Squeak
on
> Linux? Strange. I just get ´) it's a function!
> 
> But given that a class method does have access to the state in the
class
> object it is IMHO not a function. It's a class method. It can be
> inherited on the class side for example. Functions don't normally
> participate in inheritance, do they?
> 
> And given all this, in Smallscript (I am guessing here), since a
module
> is a class (and vice versa I guess) - a function in a module becomes
> just a class method (or vice versa). And you can of course have
> inheritance between modules since they are nothing else than classes.
> 
> Now... what mechanisms have you added to the "class" concept to make
it
> work as a "module concept" too?
> 
> 
> > Classes have shared/pool variables in classic Smalltalk. Therefore,
> > classes are already namespaces. Why retain SystemDictionary, or
> > non-class Pools, or introduce yet another namespace facility to
confuse
> > everyone
> 
> The Module system in 3.3alpha actually removed Pools. In the light of
> the Modules system they got redundant.
> 
> > I agree completely. That is why it pains me to see some of the ideas
> > that have been implemented for namespaces in various Smalltalks. It
is
> > also, what pains me as I see the work being done on modules, as I
> > project/foresee where it will put Squeak evolution a bit further
down
> > the road.
> 
> Could you state your prediction? Is it that the current system will
not
> be able to handle more diversified "module" concepts?
> 
> But honestly, do we really need so many different kind of modules?
> 
> We have two different beasts today - Module and DeltaModule (the names
> of the classes in question). They together capture quite a lot of
> interesting functionality IMHO. And If we will need one or two more -
> fine, we should be able to squeeze that in without too much trouble.
> 
> In short, in my opinion, which may be feebleminded since I am not even
> close to David Simmons in grasping all the meta-level questions here
> (and that was not meant as irony), I want a modules system which is
> understandable by everyone and still powerful ENOUGH. Emphasis on
> enough.
> 
> The idea to give "module" the same freedom that "class" has feels
weird
> to me. It would ALSO mean - and this is biggie - if we want to change
> the modules system we would ALSO change the class system and vice
versa.
> I personally do not want them to be that tightly coupled.
> 
> 
> [SNIP]
> > > Let's not confuse Squeak.
> >
> > I am not trying to confuse or change Squeak -- to be honest it is
> > probably not even in my best interest to assist Squeak's evolution.
It
> 
> :-) :-)
> 
> > is already changing, evolving, and maturing. I'm just trying to
provide
> > some advice for the "child" (as you've characterized it) as it
grows.
> > And, apparently, I'm doing a poor job of it.
> 
> No, you are doing just fine I think. But you need to be prepared for
> some fire when you are so bold to say we are all doing it totally
wrong.
> That hurts! :-) ;-)
> 
> regards, Göran





More information about the Squeak-dev mailing list