Java's modules rock? (was Re: election details *PLEASE READ*)
stephane.ducasse at gmail.com
Tue Mar 13 18:31:42 UTC 2007
thanks for the pointers :)
> 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
> 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-
> I can't wait to see what the COLA folks come up with!
> stephane ducasse wrote:
>> 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.
>> 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.
>>> - Andreas
> Howard Stearns
> University of Wisconsin - Madison
> Division of Information Technology
> mailto:hstearns at wisc.edu
> jabber:hstearns at wiscchat.wisc.edu
More information about the Squeak-dev