On 2011/05/08 22:45, Casey Ransberger wrote:
> 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.

I think Craig's point is that that name doesn't matter: what you call a 
Foo in your image I might call a Foozle, even though it's the same 
class/method/whatever.

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

Craig, while you're explaining that, could you expand a bit on the 
modularity aspects of Spoon? I get the versioning, and the 
lack-of-name-prevents-name-clash, but I don't see yet how it addresses 
controlling dependencies between large chunks of code.

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

It's my firmly held opinion that it's better to open your mouth only to 
change feet - as long as you learn something each time - than to never 
open your mouth.

So, by analogy, I think it's better to implement things, even brain-dead 
things that you have to rip out/apart - as long as you learn something 
each time - than to sit and talk about what the perfect system might 
look like, that would please everybody all the time.

frank

> On Sun, May 8, 2011 at 4:32 AM, Craig Latta <craig at netjam.org
> <mailto: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 <http://www.netjam.org/resume>
>     +31 06 2757 7177 <tel:%2B31%20%2006%202757%207177>
>     + 1 415 287 3547 <tel:%2B%201%20415%20%20287%203547>
>
>
>
>
>
>
>
>
> --
> Casey Ransberger
>
>
>
>