packages, not package systems (was Taking Ownership of Squeak (WAS Re: Python at Disney))

Bijan Parsia bparsia at email.unc.edu
Thu Mar 15 03:07:25 UTC 2001



On Wed, 14 Mar 2001, Lex Spoon wrote:

> While a package system would be nice, it doesn't address the bigger
> problem that the main release has several intertwined components that
> would better be separated.  
[snip]
> Change sets are fine for now.  Packages start to win big when there are
> a lot of packages and whene the interelations between packages get
> complex, but that's not yet the case.  (It's a very different stery with
> Linux -- I'm extremely happy that Debian's package tools keep track of
> my packages for me!  I've got 877 packages installed right now, and
> often the dependencies are quite complicated!)

Seems like a good junction to point out again (as I and others have) that
dependancy tracking management, packaging, modules, and a bunch of other
things are distinct. What *I* want is that things don't break easily, that
they're easy to fix, it's easy to make things that don't break, it's
easy to change stuff without breaking things that are hard to fix, and
that things are easy to understand, explore, figure out, etc.

That's all. :)

I've decided that I *don't* want a module system. Having things more
"modular" can help with some of these things, but certain kinds of
modularity just irke me. I don't really want modularity for the sake of
memory management, for example, I want my system to have intelligent
paging and persistence (LOOM anyone?). If that involves some degree of
modularity at some level, great, but I doubt it will be precisely the same
as what I'd want for "applications". Or packages. Or "libraries". Or
distribution. I don't want to have to muck with yet another abstraction
mechanism *in order* to reduce my memory usage by unloading not very used
objects.

And projects! Projects are ok, but they have some of the features that
would annoy me about (some sorts of) modules. I don't like that my change
sets align with my projects. Often I want changes to one set of classes to
go to a certain change set, and those to another to a separate change set
(*espeically* true when unit testing). But I have to switch projects or
keep a change sorter open *and* remember to switch back and forth. Yuck.

(Of course, now someone will pop up and torture me by pointing out that
Squeak has some funky magic that makes this work the way I want it to
since version 1.18. I hope.)

(Of course, then it'll turn out that it's invoked by a control key.)

(Oo, it'd be fun if Squeak did mild inferencing to determine where to slot
a change, and maybe give me a little popup for confirmation.)

Multiple change sets associated with a project would be nice too.

I slop around, but my 'projects' seem rigid. Moving stuff from project to
project seems, if not hard, then impossible.

Hmm. Thinking off the track for a moment, it's sorta like prototype
vs. classes. Prototypes are great for evolving stuff, going with the flow,
and hanging loose. And they suck when you have a bazillion of not quite
the same and not quite right objects. Classes are handy organizers, but
often they're *too much*, too rigid, too uptight. It's not *just* a matter
of ad hoc vs. upfront organization (er..that's not quite right, but
someone will understand! I have faith! :)), it's about having to make
certain decisions for the say of the organization, rather than because it
makes sense, or *not* being able to do so.

So, in conclusion: boo to modules! Q.E.D. :)

Ooooooookay, that's enough groovy, stream o' conscious rapping from *this*
had-one-too-many-cups-of-tea Squeaker!

(But I will add that I *love* the exobox shots, and think that OSProcesses
are the bee's knees.)

With the cat's pajamas unwashed,
Bijan "ctrl-freak (but not available on Windows)" Parsia

P.S. This message is *all* Lex's fault. Direct all blame and blows to
him! ;)





More information about the Squeak-dev mailing list