Java's modules rock? (was Re: election details *PLEASE READ*)
stephane ducasse
stephane.ducasse at gmail.com
Tue Mar 13 07:39:45 UTC 2007
**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
>
>
More information about the Squeak-dev
mailing list
|