miracle modules (was: Improving the aesthetics and usability of Squeak)

Andreas Raab Andreas.Raab at gmx.de
Tue Jul 9 12:35:19 UTC 2002


Hi Jecel,

> I started out writing this to contradict you but ended up mostly 
> agreeing.

Heh, heh, that's the way it goes ;-)

> This is true for a design which doesn't allow multiple versions of a 
> given module to be loaded at the same time, which seems to be 
> the case for the current effort.

Yes, having mutltiple versions of the same module would solve some of
the problems but not all of them. What it basically means is that you
would be running "an old version inside a new one" which means that
while you might be able to load the old stuff it (mostly) doesn't make
use of any of the newer features. Now for some of these things (like
more regular applications) this really doesn't matter but for others it
will. In particular when you are trying to use some older version of a
module with something that requires a newer version of it. A good
example for this is DirectX which does support "modules" (more
specifically COM-interfaces) with multiple versions. Just don't try to
mix an IDirectDraw with an IDirectDrawSurface4 ;-)

> > Point #3: Modules will not solve the problem of what is in the "base
> > image" and how to find things that are not in.
[...]
> Well, this is the case for "top level" modules. The problem 
> is when you are trying to load something that requires lots
> of other stuff to work. In that case we want something more
> like "apt-get" than "findRPM". Some module name to URL directory
> would be great. We don't care what all that stuff does, who
> wrote it and so on.

You got a certain point here although you are not answering the question
about how people find and get to the top-level modules in the first
place. It's true that modules may (hopefully will) help with structuring
stuff at the level below but without finding cool stuff first noone is
ever going to be in the situation that you'll be using any of the
support modules ;-)

> > Point #4: Modules will not solve the problem of what "the default
> > experience" should be
> 
> That is just it: you would no longer have to have "the 
> standard".

True and false. True in such that you might not "have to have" a
standard. False in such that there always will be one. Or would you want
people to set up their own window colors, frames, button preferences,
key mappings before they can even start doing things?! ;-)

> With modules you could have a set of common files adding up 
> to roughly 20MB plus a lot of very small files with the
> different "skins". The frequent updates would only affect
> a few files (possibly just one) at a time.

But that's wrong. Given (for example) Jim's Zurgle stuff in the image
you won't need modules to have your skins. What's needed for that is
parametrization not modularity.

Cheers,
  - Andreas




More information about the Squeak-dev mailing list