Doug Way wrote:
>  
> After reading this, I'm feeling better about PackageInfo "taking over"
> class categories.  I'm not sure it's worth keeping packages and class
> categories orthogonal.  Class categories just plain aren't that useful
> if you have packages, which end up forming a similar (but not
> identical) categorization.  In other words, I'm wondering if class
> categories are eventually headed for the dumpster.

I find "category-subcategory" very simple and straightforward.

I have an object model with:
- 14 subsystems
- there are between 4 and 23 object classes per subsystem,
  with most having 8 or 9 objects
- (I've not finished all the relationship classes so
   I don't have numbers for those)

I use "system-subsystem" for the categories, and a prefix
for all the class names. With Monticello, I just save
the package named "system" and I'm done. Several times
I've change the subsystem name, and I still just have to
save the "system" package. I can only imagine to hoops
were there a bunch of subpackages instead, and I had
to create, rename, create new editions, etc.

As it happens, I'm porting this code to VW, for a proof
of concept. Since I want to keep the mainline development
in Squeak/Monticello, I filein the code to packages I
created in VW. Things are a mess at the moment because
I've created packages for "system-subsystem" for some
support code, and for other bits I've only created a
single package for "system". I'll eventually settle on
one way, but the ugliest issue is that the Seaside port
on VW is in a Seaside namespace.

Now I have to import the Seaside namespace into my
packages to avoid having to change method source to
add a "Seaside." prefix to every reference to a Seaside
class. Worst of all, when I subclass a Seaside class
there is no way to avoid having to put a "Seaside."
prefix on the superclass argument. The people on
#smalltalk irc were very helpful - (thanks), but the
speculation was that there was no avoiding that prefix.

> But I'd say we definitely don't want to have all three orthogonal
> concepts in Squeak -- class categories, packages and namespaces...
> let's have two at most.

If packages are separately loadable and complete pieces of
functionality, then they are their own namespace. Then the
problem is linking of dynamically loadable modules into
the rest of the image.

Namespaces are just trying to solve the problem of name
collisions. Different solutions introduce different pain.
Prefixes have to be short, and then prefixes collide.
Namespaces, imports, dotted-names, etc. needs more
bookkeeping and leads to ambiguous names.

Something that's missing in the discussion is what level
of abstraction we're dealing with. If you're packaging
a large domain of objects, then package==namespace makes
sense. But if you're packaging a few enhancement methods,
then package==namespace, seems wrong.

--yanni