Hi Casey--

> ...I want to do my part to make sure we're looking at the *whole*
> issue. Does that make sense?

     Yes! But... :)  I also think that tying modularity to namespaces is
a big mistake.

> ...a requirement for what I would call "true modularity" wherein one
> package can only depend on any class in another package by naming the
> package *explicitly* a la:
>
> (Kernel at: Object) new. "Insert a better EDSL for name spaces here."
>
> *or* explicitly state the package we're extending in our class defs,
> a la:
>
> Object subclass: #Foo
> instanceVariableNames: 'bar baz'
> inPackage: 'Foo-Core'
> includePackages: 'Bar-Core Baz-Core'
> ...
>
> In which case our class is loaded into Foo-Core, and has access to all
> of the objects that are global only to Bar-Core and Baz-Core.

     Or separate class name from identity, by not relying on the textual
name of classes when transferring methods between object memories. Then
textual class names are completely unconstrained, and you don't need
class namespaces at all (or, effectively, every class has its own
namespace). See [1] for details.

> ...I must *strongly* urge the community to *please* pull down a Pharo
> image, load up the Environments package, and give it a test drive...
> I have to say that I thought the "language" used to express the
> trappings of namespace in Environments were rather beautiful.

     I cringed immediately, because it attempts to solve the problem of
naming constraints by introducing additional constrained names (the
names of the namespaces themselves).

     Also, we can solve the naming problem completely independently from
how behavior is organized (packages, modules, etc.). I think we should.


     thanks,

-C

[1] http://netjam.org/spoon/naiad/#namespaces

--
Craig Latta
www.netjam.org/resume
+31  06 2757 7177
+ 1 415  287 3547