Bijan Parsia wrote:
> 
> On Sun, 11 Mar 2001, Paul Fernhout wrote:
> [snip]
> > But, let's say for the sake of arguemnt you are right. Do you (or anyone
> > else) have any ideas for how to make a modular Squeak in such a way that
> > it would be easy for SqueakC to integrate it into ongoing changes?
> >
> > Here are the requirements (defined by how Python does things):
> 
> Yeek. Let's *not* make Python the be all and end all or even the
> *standard* model for modularity. It's a good place to look, but it's got
> it's own set of pitfalls (PYTHONPATH anyone? Not as bad as Java's
> CLASSPATH but still often sticky; a friend dealing with Mojonation had
> loads of trouble getting it running, in part because of module import
> weirdness; etc. etc.).

Good points.  (I'm certainly familiar with CLASSPATH ugliness, at least.)

> ...
> The most annoying bit of Python is the file/module correspondence (which,
> admittedly, is the best way I know of off hand to do that sort of module
> stuff)---files are *bad*, evil, wrong!!! :)

Squeak wouldn't have this problem, at least. :)

> There are lots and lots of module/modularity devices (as you point out,
> Smalltalk's classes do a fair job), a lot of different ways and things one
> might want modularized, and a lot of different ways to do it. Some are
> compatible with a monolithic image! (E.g., Common Lisp's package system).

A reasonable proposal for a module might be that it contains any number of classes, and also any number of method "extensions", i.e. individual methods which can be added to the classes of prerequisite modules, provided the methods do *not* already exist.  (Does Python allow this?  I know Java doesn't.)  I don't think treating individual Smalltalk classes as modules would be a great idea, actually.

> ...
> (AFAICT, what Squeak is currently missing is: package *un*loading, pre and
> post load scripts, and a divorce from ui stuff. Can one unload a project
> (such that, the classes "in" the project get removed from the system)?)

This is the crucial stuff.  I think the ability to simply unload a project isn't there right now (Ned Konz recently posted about trying to do this), but I imagine that SqC must be working on this.  They've recently segmented things so that a 4MB kernel can download projects from the net... if there's going to be a bunch of content available on the net as projects as part of 3.1, then people will be trying to load different projects into an image, and I'd think you'd need to be able to unload projects or your image would fill up pretty quickly while trying stuff.  (I don't know for sure, though.)

> > 3) Supporting namespaces for a module for sanity and to ensure needed
> > classes are loaded (like Python)
> 
> Namespaces are, imho, an even trickier issue. But there are a bunch of
> models, even within the Smalltalk world (Visualworks, Smalltalk/X, others
> I'm sure, various detailed proposals). Maybe we should look at them.

Yes, namespaces are tricky.  You might even be able to get by without them for a first pass at modules, I dunno.  At least VisualWorks got by without them for awhile before 5i... companies building packages would prefix all classes with a few unique initials.  Okay, perhaps this isn't ideal.

One thing that's annoying about namespaces in Java, at least (and probably in general), is that developers sometimes use a generic name for a new class, such as "Date", but it's really a special kind of Date relevant only to that package.  People looking at the source code may mistake declarations of Date as being the more standard Date, not the specialized one in the package.  The specialized Date should have had a more descriptive name, such as JulianDate, or whatever, but the developer didn't bother because namespaces allowed him to use just plain "Date".  (This was a real-world example that I ran into in Java, for what it's worth.  I guess it's a bigger problem in statically-typed languages, where you have to have declarations everywhere... at least it
wouldn't be as bad in Squeak (or Python), since class names don't need to show up as often in source code.)

- Doug Way
  dway at riskmetrics.com