[Modules] Getting on a common page

Stephen Pair spair at advantive.com
Thu Aug 16 17:48:32 UTC 2001


Clearly, Squeak currently suffers from it's own form of DLL hell.  It's
that problem that I think a modularity system should attempt to solve.

Here is what I would like a Squeak modularity solution to allow me to
do:

- write code and have it not affect any other aspects (modules) of the
system, unless that is explicity desired, automatically capturing (and
warning) about dependencies on other modules along the way
- export that code out of the the image
- install that code in another image (with a tool to locate and load
suitable implementors of pre-requisite modules...potentially allowing a
package implementor to customize what constitutes a suitable implementor
of a pre-requisite package (i.e. a specific version, a range of
versions, or that a package declares itself to be compatible with a
named package interface))
- uninstall that code, leaving the image exactly as it was before
installation

Regarding the whole notion of module dependency...I see this problem as
essentially this:

	- you write a package that depends on another package's
capabilities
	- you need to capture this requirement somehow
	- so simply state that you need package XYZv1 or package XYZv2
or a suitable substitute for either of those two packages.
	- another package implementor can determine whether their
package can act as a suitable substitute for package XYZ
	- you then need some mechanism to resolve these pre-req
requirements into actual packages 

I think a lot of packaging systems work exactly like this (Tcl comes to
mind).  Having some mechanism that acts as a registry of package
interfaces (with primary name, followed by some qualifier, such as a
version) with a set of implementors would be desirable.  The user of
that registry could then select (upon loading a module) which
implementor to use (or just use the closest match available).  If you
are loading modules dynamically, you could explicity define how
interfaces are mapped to implementors (and this mapping could overridden
for specific modules).

- Stephen


> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Allen Wirfs-Brock
> Sent: Thursday, August 16, 2001 12:49 PM
> To: squeak-dev at lists.squeakfoundation.org
> Cc: modsqueak at bluefish.se
> Subject: [Modules] Getting on a common page
> 
> 
> Since Dan and Dave Thomas asked me to participate in this 
> discussion I've 
> been thinking how I could best contribute.  As I'm not going 
> to have the 
> time to actually implement anything I think the roles I can 
> probably play 
> are tour guide and ideologist.  This is a lot of work, good 
> ideas, and 
> experience both inside and outside the Smalltalk community 
> relating to 
> modularity.  As a tour guide I can make some of this visible 
> and perhaps 
> provide some interpretation.
> 
> Smalltalk is built upon an ideology of objects. The ideology 
> binds the 
> community giving them a common perspective on computing and a common 
> language to communicate about computation. In looking at the on going 
> discussions on the [Modules] topic it's easy to see that 
> there isn't yet a 
> common ideology of Modules for Squeak.  You need one!
> 
> The potential scope covered by the subject heading "modularity" is 
> huge.  It essentially covers every aspect of what used to be call 
> "programming in large". As I was composing my thoughts on 
> things I would 
> like to share with this list I realized that I was developing 
> the mental 
> outline of what could be a book length work.  In order to 
> make progress we 
> are going to have to focus on the essentials.  Henrick has 
> already said as 
> much:
> 
> >I previously (off-list, not your fault that you didn't get 
> it) argued 
> >that we need to modularize the modularity effort itself, if 
> we are to 
> >ever get anything done. To do so we need separable, small, 
> incremental 
> >steps. We need to identify  the 'core' that must be done and 
> should be 
> >done first.
> 
> I heartily agree. I would urge everybody with an interest in 
> this area to 
> focus, for the next few weeks, on defining that core.
> 
> Allen
> 
> 
> 





More information about the Squeak-dev mailing list