thanks for the pointers :)

Stef

> Dylan was developed at Apple and highly influenced by Bobrow/ 
> Kiczales/desRivieres', etc. pre-AOP work.
Art of MetaObject protocol and open-Implementation are cool :)

>
> 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
>
>