Hey Craig,

Sounds really interesting. FWIW I like "named" namespaces because they make
searching a codebase for dependencies easier. At the end of the day, one
ends up with far less namespaces than one has classes, and in my own
experience, that's a lot more manageable than what we have now.

That said, I'll try anything once. I've seen a *wealth* of *great* ideas
about how to do namespaces in Squeak... but I've only seen one working
implementation, which is at present irksomely dependent on OmniBrowser --
something I don't see in a kernel image. Is the approach suggested in your
paper something I can currently download and install? It looks like Naiad
means I'd have to give up my .sources and .changes files, is this correct? I
might do that if I got namespaces back in exchange. I will spend some time
reading your paper tonight:)

I guess I should just out and say it: I don't see a shortage of proposals
around here, I see a shortage of consensus and a shortage of implementation.
I'm hoping if I keep harping on it long enough, folks will actually *try*
one of these approaches, because as it is, the lack of namespaces is a
strong barrier to my mapping Squeak onto a local industry that's currently
in love with Ruby, something I'd really like to do:)

I care less about what the approach is than I care about whether or not I
can use it now, which I believe puts me in the minority on squeak-dev!

On Sun, May 8, 2011 at 4:32 AM, Craig Latta <craig at netjam.org> wrote:

>
> 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
>
>
>
>
>
>


-- 
Casey Ransberger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20110508/c87a89c4/attachment.htm