Hi Andreas, thanks for responding.

Andreas.Raab at gmx.de wrote:
> > 	I agree packages are useful for conceptualizing subsystems, but I will
> > argue that classes can serve this role as well.
> 
> Sometimes they can, but (I think) only if they present a facade which hides
> the intrinsic complexities of the stuff behind it. This is true for the
> compiler and some other subsystems but nor for all of them. Best example:
> Collections.

I think the Collection class could represent the subsystem of all
collections.  Its class vars could be UnorderedCollection,
SequeaceableCollection, and so on.  And these could hold more specific
classes and so on.  A system category can change into an abstract class
if it helps to keep it around.  This technique could be used for
subsystems that don't have a facade class.

> *Way* too much complexity in a single place for my taste. By the end of that
> scheme you would have lots of distinctive responsibilities merged into a
> single place - namely that of being a class (describing instance behavior), that
> of being a "utility belt" for methods(those two already get really
> confusing) and then also being a package and being a name space. Without a way of
> getting a clear understanding what is what the result will be utter chaos.

But your right that I'm putting too many roles into classes.  I would
have no problem with having a separate module object that served as the
namespace/package for several classes.  Then modules could represent
subsystems and you can disregard my argument above.  But I would still
keep automatic detection of prerequisites as I have described in
previous posts, which means adding mulitple inheritance (to avoid class
extensions) and selector binding to protocol/abstract class.
	Automatic detection of prerequisites has been the driving force behind
my proposal.  Dependencies are already inherent in the code and we
should utilize them.  We should not manually specify dependencies since
it is extra work and it can get out of sync with the code.

> And it doesn't even solve any of the packaging problems.

I believe automatic detection of prerequisites does solve a key problem
of packaging.

> And with objects we don't even need classes. That's not the point. The
> concept of packages is simply a useful one - similar to that of having classes.
> Besides, I think that even if that scheme could be implemented (which I have
> strong doubts about) I don't think very many people could grok it. Might be
> worthwhile to consider.

Point well taken.  As I said above, package/module can be a separate
object that holds a set of classes.  But I would keep it just that, and
not introduce class extensions (methods for other classes), but instead
use mulitple inheritance.  And further, I would not manually specify
dependencies but infer them from the class's methods using selectors
bound to abstract classes and my prerequisite tracing (download)
algorithm described in my original post entitled "Class Dependencies".

Thanks,
Anthony