I spend some effort to summarize those work. If you are interested in  
this...

http://www.iam.unibe.ch/~scg/Archive/Papers/Berg05cModuleDiversity.pdf

Related work in:
http://www.iam.unibe.ch/~scg/Archive/Papers/Berg05bclassboxjOOPSLA.pdf

Cheers,
Alexandre

On 23 Jan 2008, at 15:16, Jason Johnson wrote:

> Wonderful, thanks.  I dig through those and see if I find something
> like what I'm envisioning.
>
> On Jan 23, 2008 3:10 PM, Bergel, Alexandre <bergel at iam.unibe.ch>  
> wrote:
>> There has been many propositions like this: J&, MZScheme's Unit,
>> Selector Namespaces, Method Namespaces, Expander, Java Module System,
>> Jiazzy, ... I could say another 20 more.
>>
>> I see that the three main difficulties in adding a module system in a
>> programming language are:
>>         - Turning non-modularized libraries into modularized one
>>         - Preserving backward compatibility
>>         - Getting the community accept the proposal
>>
>> Cheers,
>> Alexandre
>>
>>
>>
>> On 23 Jan 2008, at 08:28, Reinout Heeck wrote:
>>
>>> Jason Johnson wrote:
>>>> Hi all,
>>>> Recently working in other high level languages I was thinking about
>>>> how modularity is accomplished in these systems and how we might
>>>> do it
>>>> in Squeak.
>>>
>>>
>>> This is a recurring discussion and I often see suggestions like
>>> yours: postulate a mechanism and discuss its viability. I would
>>> call this the bottom-up approach.
>>>
>>> If we went top-down we could start with specifying what we want to
>>> get from a module system. I recently came across a paper on J&
>>> ('Jet') which starts out with a list of requirements we might want
>>> to ponder in this regard:
>>>
>>>
>>>
>>> http://lambda-the-ultimate.org/node/2591
>>> "
>>> J&: Nested Intersection for Scalable Software Composition by
>>> Nathaniel Nystrom, Xin Qi, Andrew C. Myers. 2006.
>>>
>>>     We identify the following requirements for general extension
>>> and composition of software systems:
>>>
>>>        1. Orthogonal extension: Extensions may require both new
>>> data types and new operations.
>>>        2. Type safety: Extensions cannot create run-time type  
>>> errors.
>>>        3. Modularity: The base system can be extended without
>>> modifying or recompiling its code.
>>>        4. Scalability: Extensions should be scalable. The amount of
>>> code needed should be proportional to the functionality added.
>>>        5. Non-destructive extension: The base system should still
>>> be available for use within the extended system.
>>>        6. Composability of extensions.
>>>
>>>     The first three of these requirements correspond to Wadler's
>>> expression problem. Scalability (4) is often but not necessarily
>>> satisfied by supporting separate compilation; it is important for
>>> extending large software. Non-destructive extension (5) enables
>>> existing clients of the base system and also the extended system
>>> itself to interoperate with code and data of the base system, an
>>> important requirement for backward compatibility. Nested
>>> inheritance addresses the first five requirements, but it does not
>>> support extension composition. Nested intersection adds this
>>> capability.
>>> "
>>>
>>>
>>> IMO point 5 is often overlooked in Smalltalk systems, we love
>>> extending base code but we hardly ever think about isolating these
>>> extensions so the base code dependents don't get 'confused' by
>>> those extensions.
>>>
>>>
>>>
>>> R
>>> -
>>>
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.