I've been following this thread with great interest and have a few 
questions.

I really like the idea of modules and, more specifically, of Squeak 
being declarative (i.e. build images from the ground up rather than 
strip images).

As I understand it, modules will contain classes which implement 
functionality on top of some base set of modules upon which that module 
depends.  Delta modules will contain new and updated methods on other 
classes in other modules.  Is this understanding correct?

If this is the case, how are we going to deal with interface conflicts? 
 The scenario I'm wondering about is this:

First, I load module A.  Class Foo in module A implements #bar which 
calculates the size of the universe and answers a LargeInteger.  Now I 
load delta module B which redefines Foo>>bar to answer a random string 
from Shakespeare's "Romeo and Juliet".  What happens when I load module 
C which sends bar to Foo and expects the size of the universe back? 
 Will these interfaces be overloaded based on module dependencies?

While I'm not the elite Squeak hacker yet, I am interested in offering 
support for development of modules.  I had hoped next to build an Ogg 
Vorbis plugin (I know Craig Latta is working on the same), but would be 
willing to put that aside to offer my meager spare time on further 
implementing modules.

Andreas Raab wrote:

>Hi Göran,
>
>  
>
>>>I have always liked (I still do) the general approach
>>>that Henrik took due to its nice algebraic properties 
>>>      
>>>
>>That is nice to hear - then I am not alone in thinking that 
>>at least the ideas are "ok".
>>    
>>
>
>You might want to be careful about interpreting me that way. When I say
>I like the "algebraic properties" it does not automatically imply that I
>think they're a "good idea". Some of them I believe aren't. Or rather
>"aren't for people".
>
>  "One must learn to distinguish between 
>   what is true and what is real"
>     - A. Einstein
>
>Here is a simple one: Giving the module-hierarchy a "meaning" of any
>sorts. It's a perfectly fine thing to do in abstract algebraic
>environment but once it comes to modules and (more importantly) to how
>people _use_ them, it becomes very quickly clear that there's simply no
>unique meaning for a hierarchy. E.g., when you organize stuff
>hierarchically there's simply no unique scheme by which you go - I find
>myself using various models each of which depends on the concrete
>context I'm in. I thought about this for a long time (and had a couple
>of good discussions with Stephane about this point) since I used to
>think that a meaning in this hierarchy would be really valuable but in
>the end I decided that while it is "algebraically nice" it is still not
>a "good idea" for a module system to imply any meaning in hierarchies.
>
>Similar for name spaces. From a more abstract point of view, it is
>perfectly legal (and very useful) to give each module its own name
>space. But when it comes to practical use ... uh ah ... Like Avi was
>saying, is this really the big problem? (or in other words: a "good
>idea"?!)
>
>That said, I still think that parts of the design ideas are brilliant.
>Conceptually, I _love_ the idea of delta modules as being the "bridges"
>across different parts of the environment. Stephane has a valid point in
>his argument about how to explain these but I believe that a lot of this
>can be hidden - e.g., does a user _ever_ have to see the deltas?! I
>would argue that he doesn't - from a UI point of view the system could
>handle the "delta separation" while giving you the view of that module
>as one homogenous entity. I claim that for 99% of all cases this is just
>what you need and then you get all the other nice properties from it for
>free (oh, and just by the way, I do _not_ like deltas for replacing
>change sets - they serve very different purposes in my understanding).
>
>  
>
>>>Also, there's this problem that at this point there
>>>is not a single concrete advantage for anyone actually
>>>using the module system - it's still in an abstract
>>>place in the future where "everything is going to get better" etc.
>>>      
>>>
>>Yes, this is also the main reason IMHO that so few are trying
>>to push 3.3 ahead. As Avi wrote - (paraphrasing) if I can't work
>>*in* it then I won't work *on* it.
>>
>>That is probably... THE biggest problem with 3.3 and Modules.
>>    
>>
>
>No, actually I don't think so. I think the biggest problem is complexity
>and backwards compatibility. There are not very many people who really
>_need_ modules in a deep way (if there are more than ten people on this
>list I'd be surprised). Those who do have probably looked at the modules
>stuff. Let's take Avi (it would be worthwhile if you could say a few
>words about this yourself) and ask the question why exactly he hasn't
>done his work in the context of 3.3alpha?! For the things that I did,
>the answers are: #1 I need this with serious amounts of stuff working
>within 3.2 and porting (and while porting finding and fixing bugs in the
>module system) is not really an option. #2 It's been too hard to fit
>into specific places of the modules system because you got to understand
>too many of the details.
>
>For a community effort it might just not be a good idea to concentrate
>that many responsibilities in a single place. I think it'd be relatively
>simple to handle all of the problems independently (e.g., source code
>access, class definitions, versioning, packaging, name spaces) and then,
>once the individual parts are there have a brainstorming session about
>who should use what in which context and how they all play together. At
>the very least people could try out individual stuff (which - as your
>and Avi's work show - is useful on its own) before they buy into the
>larger changes. Sure, it may not be as nice of an algebra, but I think
>it'd be much more "real". 
>
>  
>
>>But does this mean we should drop Modules(as in Henrik's code)?
>>    
>>
>
>I told you, don't expect any answers from me. I would find it a horrible
>waste of effort to dump all of it in particular considering the nice
>stuff that's in there. That said, I do believe that the only way to make
>this module system work is to have someone who deeply understands the
>overall design and is willing to "carve out" small enough tasks for
>collaborators which will in the end lead to a working overall system. I
>can't be that person (I simply don't have time for it) and Henrik
>doesn't either. Who else could and would?! And given that there's no
>benefit for anyone at this point the question needs to be asked if
>insisting on "fixing it" is helping at all, or if it isn't rather
>getting into the way.
>
>Usually, I'd say "let's vote by feet" and bring in the alternatives and
>may the best code win. Unfortunately, it's not that simple with the
>modules since they are not easily "extracted" from the system (remember
>the "modularizing modules" thread?!) and the incompatibilities make it
>even harder.
>
>Cheers,
>  - Andreas
>
>  
>

-- 
Jason Dufair - jase at dufair.org
http://www.dufair.org/
<xterm> The problem with America is stupidity. I'm not saying there
should be a capital punishment for stupidity, but why don't we just
take the safety labels off of everything and let the problem solve
itself?