Roel Wuyts <Roel.Wuyts at ulb.ac.be> writes:
> I have the impression that the thread seems to revolve partly about
> two hidden and different assumptions (bear with me for the moment):
> - Andreas seems to be defending an 'anticipated reuse' model, where a
> module is a well-encapsulated black-box entity. Indeed, running in a
> different image ( 'classloader' :-) ) quite strongly enforces this
> encapsulation.
> . Lex seems to be more in favour of an 'unanticipated reuse' model
> where anybody can add elements.

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?

Dealing with inter-module problems, as Andreas describes, is very
important!  However, to address those problems well, we need to treat
the suite of available modules as itself a thing we are developing.
Then we can file bugs against the suite itself and develop it just
like any other software artifact.

DLL hell is basically absent in Debian.  It is truly sweet to install
packages via Debian, because all the library dependencies are sorted
out already for you.

For anyone who is involved in a project facing DLL hell, I suggest
making an APT repository and a bug tracker and giving it a try.  This
setup eliminates the routine forms of DLL hell, and it turns the hard
cases into normal old bug reports.


To return to the topic at hand, it would be great to see better module
systems.  Classboxes are real cool, as are the ideas Andreas has
floated in this thread.  However, please leave in an override
mechanism.  Make the walls advisory, not mandatory, just like in
Smalltalk of today.

  -Lex