Transactions as Modules (was: Behaviors vs Modules)

David Simmons David.Simmons at smallscript.com
Sun Feb 24 00:48:41 UTC 2002


> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org [mailto:squeak-dev-
> admin at lists.squeakfoundation.org] On Behalf Of Anthony Hannan
> Sent: Saturday, February 23, 2002 2:37 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Transactions as Modules (was: Behaviors vs Modules)
> 
> One thing I don't like about having protocol behavior loaded together
as
> a single unit is that it is likely that a program crosses many
protocols
> instead of just staying in one or a few of them, requiring many loads
> instead of just a few.  One solution is to not have protocols, and
only
> load and trace default methods of selectors we are using.  But this
fine
> granularity even increases the number of loads.
> 
> Related to module functionality is database functionality, which has
> largely been missing from the module discussion.  

This is how modules were built in QKS Smalltalk (SmalltalkAgents). The
built in repository provided multiple databases for modules. 

In SmallScript, a module is logically a repository (database). That is
why it needs to be a class so that the type of database it implements
can be defined and controlled by the module definition itself.

> But I think the two
> should be treated together since loading and saving modules is just a
> special case of loading and saving objects in general.  

I agree. That's why I've made the comments that modules (for
SmallScript) are effectively modularized images.

> Methods that
> call each other should be grouped together so they can be loaded
> together.  When we program we usually write methods that call each,
> together, and when we're at a stopping point we save.  We usually put
> all these methods into a single changeset.  A changeset is equivalent
to
> a transaction.  But instead of the forgetting the transaction after
the
> changes are applied to the database/image, we want to keep it around
as
> a separate loadable entity, as a module.

> 	A module can be defined as a collection of objects.  Some of
these
> objects may shadow other objects (ie. the shadowed object will become:
> the new object when loaded).  Shadowing is how one module makes
changes
> to another module but without replacing it.  Later, the overriding
> module (or part of it) can be merged in with the original module once
> its changes are considered stable.  Every object would belong to one
and
> only one module.  Cross-module pointers would become disk proxy
pointers
> when the referenced module is not loaded.  Traversing a proxy pointer
> would cause the referenced module to be loaded.  ImageSegments are a
lot
> like modules decribed here and I would like to reuse its quick binary
> format and root & outPointers structure.
> 	When working in your image there would always be a current
module
> active where all new and changed objects would be placed.  Upon
commit,
> the module will be written out to a repository so others can see it.
At
> this point the module can stay as the current active module to be
> changed further, or a new one can be started, depending on the commit
> command issued (save vs commit, or something).
> 	Of course there is the issue of the repository, distributed or
> central,
> how to manage concurrency, consistency, priviledges, etc.  We could
use
> a traditional database system with just one table called Modules where
> each record is a module with fields id and imageSegmentBitStream; or
we
> can build our own database system.  A consistency check needed in
either
> system would be to make sure cross-module pointers are still good.  If
I
> save a module, the database has to make sure the modules it points to
> haven't changed since last time I loaded them, otherwise I could have
> dangling references.
> 	One important module would be the one containing the Smalltalk
> dictionary (or root category).  It would contain (proxy) pointers to
all
> other top-level objects available in Squeak.  So if someone want to
make
> new objects/functionality available to everyone, s/he would just add a
> pointer in the Smalltalk root and update its module.
> Namespaces/categories/environments would be orthogonal to
> modules/transactions.
> 
> I like this better than behaviors as modules.  Of course I still like
> default selector behavior for mixin capability, we just don't need the
> protocol grouping anymore.  What do you guys think?
> 
> Cheers,
> Anthony

-- Dave S. [SmallScript Corp]

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




More information about the Squeak-dev mailing list