Java's modules rock? (was Re: election details *PLEASE READ*)

Howard Stearns hstearns at wisc.edu
Tue Mar 13 14:04:57 UTC 2007


Dylan was developed at Apple and highly influenced by 
Bobrow/Kiczales/desRivieres', etc. pre-AOP work.

It formalized the concept of sealing a domain against extension or replacement.
http://www.opendylan.org/books/drm/Sealing

It's all very nicely done, but is based on multiple-inheritance AND multi-method 
dispatch. It is not clear to me if applying this would be easier due to the 
simplicity of Smalltalk, or harder because of the lack of a simplifying 
higher-level abstraction (which sometimes makes it attractive for people to work 
around stuff in a more ad hoc but less "sealable" way).

Curl is somewhat closer to Smalltalk in this respect. It abandons sealing in 
favor of specifying a version range in the code by which one module includes 
another. Internal renaming is used to allow multiple versions of the same module 
to be used by different parts of the same application.(I can't find a reference, 
but http://en.wikibooks.org/wiki/Curl#Version_numbers is a start.) In other 
words, it keeps old stuff working by not allowing you to change that which is 
already used underneath existing stuff. It is anti-OpenImplementation.

I can't wait to see what the COLA folks come up with!

-H

stephane ducasse wrote:
> **thanks**
> I like this kind of discussions. (I hope to get someone working on 
> solution 3 but money is scarce :)
> 
> Now about modules, I found several occasions (and this is also the idea 
> behing open implementation of kiczales
> before they went in aop) is that the boundary of modules are often at 
> the wrong level of abstraction since
> sometimes you want to be able to change deep implementation points. So 
> in some cases (network for example)
> people do not want to use library since they lose their ability to 
> control low level.
> Some people pointed to me ml functors with the experience that it was 
> powerful but that often people were
> using functors on functors on functors leading to system that noone can 
> understand.
> 
> Stef
> 
> On 10 mars 07, at 22:16, Andreas Raab wrote:
> 
>> stephane ducasse wrote:
>>> Did you encounter cases where you would have like to have different 
>>> versions of the same component/modules running in the same image.
>>
>> Sure. Consider Croquet: It relies on replicated computation which 
>> means that the replicated islands must have identical code based to 
>> have the same behavior. But what happens when you link to a space 
>> which uses a different (older or newer) version of a module that is 
>> already loaded in the space you are in? As far I can see there are 
>> only three options:]
>>
>> 1. Don't ever allow it. That's our current solution, i.e. all spaces 
>> linked together must use the same code base. For the obvious reasons 
>> this is neither particularly scalable nor desirable.
>>
>> 2. Force migration of "older" spaces. This may be an acceptable 
>> solution if the number of spaces linked together is relatively small. 
>> However it has the disadvantage that you create "waves" of updates 
>> since participants are linked together in unforeseen ways (compare 
>> this to a WWW where each web page can only be linked to another 
>> webpage of the same version and where upgrading one would implicitly 
>> require upgrade all the ones it links to - I think you can see the 
>> basic problem with the approach).
>>
>> 3. Have these modules sit side-by-side. In reality, this is the only 
>> scalable, secure and desirable solution.
>>
>> Cheers,
>>   - Andreas
>>
>>
> 
> 

-- 
Howard Stearns
University of Wisconsin - Madison
Division of Information Technology
mailto:hstearns at wisc.edu
jabber:hstearns at wiscchat.wisc.edu
voice:+1-608-262-3724



More information about the Squeak-dev mailing list