Stephan -

Thanks for your comments and questions.  You are definitely thinking along the same lines.

	- Dan

Here is some further discussion...
-----------------------------------
>Perhaps I'm repeating some earlier thoughts, but in spite of this I want to
>add a few remarks:
>
>> 3.  Pkg Thing
>
>Best form I think.

Yes.  I'm pretty sure of this now.

>But how to realize it with PackageDictionaries (see below)?
(also see below) each package will be an instance of a mechanically generated subclass of the class of its enclosing package.  This provides a method dictionary for the export protocol and a superclass link for inheritance.

>To ensure that I have hit the point: And so no name clashes between classes
>in different packages?

There is only one form of "clash" possible:  namely between levels in the "open access" inheritance structure.  All others are directed references of the form 'Pkg Thing'.  The open access references of the form 'Thing' are analogous to message sends of the form 'self x', and I intend to allow local bindings to override global ones.  Then if you want to override that default scope (analogous to super), you can simply use the 'Pkg Thing' form, naming an outer name space.

<many following comments in agreement with this snipped...>

By the way, I too now favor subclassing SystemDictionary (or equivalent).  The compilation change is minimal, and I think it's best not to add any confusion to classes and classVars as they are.

Even browser access is simple.  I'm planning to name packages in a formulaic manner:
	SmalltalkPackage subclass: #SoundPackage, etc.
where Smalltalk class == SmalltalkPackage, and Sound class would == SoundPackage.  As soon as things are debugged and stable, we would probably extend our browsers to view the packages nicely, and stop showing their classes at all (since they will all be mechanically generated anyway).