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

> Lex Spoon wrote:
>> Yes, that is fair generalization.  I would like the default module
>> format to allow unanticipated reuse.  Just look at the packages
>> Squeakers post for each other, and you will see all kinds of things
>> that modify the system.  How could you write something like Shout  
>> if a
>> module cannot change the system text editor?
>
> Err, by refactoring it in a way so that you can? We have already  
> various abstractions (AppRegistry) and there is nothing wrong to  
> have one that allows for syntax highlighting - with a common  
> protocol that allows other clients to hook into it, instead of  
> hacking the system text editor directly. Coincidentally, this is  
> *precisely* what I referred to earlier wrt. explicit vs. implicit  
> interactions. As it stands, loading an alternative syntax  
> highlighter will (almost necessarily) clash with shout; with that  
> interface both modules could use the same ground rules, could be  
> loaded side by side and could be activated depending on the context  
> you need them in.
>
> Cheers,
>   - Andreas
>

> Roel Wuyts wrote:
>> Andreas, I prefer refactoring, but refactoring assumes a closed  
>> world approach where you control all the pieces of the puzzle.
>
> I would call access to all pieces of the puzzle "open" not "closed"  
> but be that as it may...
>
>> It simply is not always possible to refactor (because you do not  
>> have the source, because you do not want to create a fork, because  
>> you have other programs that absolutely rely on the old behaviour,  
>> etc.). In that case extending the existing software from within  
>> your own package helps, but should be used sparingly for all the  
>> reasons you mention.
>> Note that a decent module system should support both.
>
> Which I have advocated earlier myself. I have never doubted that  
> there are situation in which patching another module is  
> advantageous and desirable. Which is why I don't understand why  
> some people are so opposed to the idea of having the other end of  
> the spectrum (isolation) available as well.
>
> Cheers,
>   - Andreas
>

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

> Those are extreme examples.  There are a lot of intermediate examples,
> too, where you want to add a few thing to Object to make everything go
> smoothly.  Look at the code for GOODS or SIXX sometime.  GOODS adds
> "isGoodsImmutable", which I guess you would say should be supported
> through a type-check mechanism.  Fair enough.  How about SIXX's addition
> of Object>>sixxInitialize ?  This method is supposed to be called
> when an object has finished initializing.  It cries out to be placed
> in class Object, so that you can just send this message to the object
> and let it take care of it.  In this case, I don't even think the system
> code should be refactored -- this is a great Smalltalk design the way
> it is.

> Indeed. I think we need both. In the same model.
>
> On 12 Mar 2007, at 12 March/08:32, Andreas Raab wrote:
>> Roel Wuyts wrote:
>>> Andreas, I prefer refactoring, but refactoring assumes a closed  
>>> world approach where you control all the pieces of the puzzle.
>>
>> I would call access to all pieces of the puzzle "open" not  
>> "closed" but be that as it may...
>>
>>> It simply is not always possible to refactor (because you do not  
>>> have the source, because you do not want to create a fork,  
>>> because you have other programs that absolutely rely on the old  
>>> behaviour, etc.). In that case extending the existing software  
>>> from within your own package helps, but should be used sparingly  
>>> for all the reasons you mention.
>>> Note that a decent module system should support both.
>>
>> Which I have advocated earlier myself. I have never doubted that  
>> there are situation in which patching another module is  
>> advantageous and desirable. Which is why I don't understand why  
>> some people are so opposed to the idea of having the other end of  
>> the spectrum (isolation) available as well.
>>
>> Cheers,
>>   - Andreas
>>
>
>
>

> Roel Wuyts <[hidden email]> writes:
> > Andreas, I prefer refactoring, but refactoring assumes a closed world
> > approach where you control all the pieces of the puzzle.
> >
> > It simply is not always possible to refactor (because you do not have
> > the source, because you do not want to create a fork, because you
> > have other programs that absolutely rely on the old behaviour, etc.).
>
> Exactly.  It also assumes that even if you have the code, you can
> convince the other guy to make the change.  This is a significant
> burden.  You are better off if you can propose your module and then
> let people try it.  If it is popular, then the other guy will know
> your code is not loopy and so will be more amenable to cooperating on
> a refactoring.
>
>
> Shout replaces the system text editor, which in my mind is an invasive
> change that is just the sort of thing hard-shelled modules would be
> likely to disallow.  I can assure you, the behavior of a lot of things
> changes when you have Shout loaded.

> For example, ShoutMonticello enables Shout in Monticello, and  
> overrides
> MCTool>>textMorph: to force it to use MorphicTextEditor default ,  
> rather than
> PluggableTextMorph.
>
> Similarly, ShoutOmniBrowser, overrides MCDefinitionPanel>>morph to  
> force the use
> of MorphicTextEditor default, instead of OBPluggableTextMorph.
> [...]
> They are distributed as .mcz files, on SqueakMap and SqueakSource,  
> mainly for
> convenience.

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

>
> 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:[hidden email]
> jabber:[hidden email]
> voice:+1-608-262-3724
>
>

> Lex Spoon wrote:
> > Shout replaces the system text editor, which in my mind is an invasive
> > change that is just the sort of thing hard-shelled modules would be
> > likely to disallow.
>
> Not at all. Shout uses an API (AppRegistry) that is specifically
> provided for clients so they can pick up an alternative text editor if
> they choose to. No module system in the world would disallow
> interaction that is based on an explicitly provided API. Besides why
> do you call the change "invasive"? It does not touch any code in the
> system text editor, all it does is using an API that was explicitly
> provided for that purpose. Why is that "invasive"?

> > There are plenty of other examples, though.  Extreme examples would be
> > Zurgle and Genie.  These old packages changed various classes in
> > Morphic when they were loaded.  Interestingly, one became standard,
> > and the other faded and stopped being maintained.  Open modules worked
> > well for these cases; they let the proponents post their code for
> > people to play with, without immediately needing to get the standard
> > Morphic classes refactored to suit them.  And anyway, they were both
> > probably lobbying for standard inclusion, anyway, so refactoring
> > hooks for them would be superfluous overengineering.
>
> Oh, that's cheap. It's not even worth responding.

> > Those are extreme examples.  There are a lot of intermediate examples,
> > too, where you want to add a few thing to Object to make everything go
> > smoothly.  Look at the code for GOODS or SIXX sometime.  GOODS adds
> > "isGoodsImmutable", which I guess you would say should be supported
> > through a type-check mechanism.  Fair enough.  How about SIXX's addition
> > of Object>>sixxInitialize ?  This method is supposed to be called
> > when an object has finished initializing.  It cries out to be placed
> > in class Object, so that you can just send this message to the object
> > and let it take care of it.  In this case, I don't even think the system
> > code should be refactored -- this is a great Smalltalk design the way
> > it is.
>
> Not having looked at SIXX, it is of course hard to answer the question
> concretely. However, it isn't exactly the first time this problem has
> come up and with a type-test this simply becomes:
>
> SIXX>>sendInitializeTo: anObject
> anObject isSixxObject ifTrue:[anObject sixxInitialize].