Hey Craig,<div><br></div><div>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. </div>
<div><br></div><div>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:)</div>
<div><br></div><div>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:)</div>
<div><br></div><div>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!</div><div><br><div class="gmail_quote">On Sun, May 8, 2011 at 4:32 AM, Craig Latta <span dir="ltr"><<a href="mailto:craig@netjam.org">craig@netjam.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
Hi Casey--<br>
<br>
> ...I want to do my part to make sure we're looking at the *whole*<br>
<div class="im">> issue. Does that make sense?<br>
<br>
</div> Yes! But... :) I also think that tying modularity to namespaces is<br>
a big mistake.<br>
<br>
> ...a requirement for what I would call "true modularity" wherein one<br>
<div class="im">> package can only depend on any class in another package by naming the<br>
> package *explicitly* a la:<br>
><br>
> (Kernel at: Object) new. "Insert a better EDSL for name spaces here."<br>
><br>
> *or* explicitly state the package we're extending in our class defs,<br>
> a la:<br>
><br>
> Object subclass: #Foo<br>
> instanceVariableNames: 'bar baz'<br>
> inPackage: 'Foo-Core'<br>
> includePackages: 'Bar-Core Baz-Core'<br>
> ...<br>
><br>
> In which case our class is loaded into Foo-Core, and has access to all<br>
> of the objects that are global only to Bar-Core and Baz-Core.<br>
<br>
</div> Or separate class name from identity, by not relying on the textual<br>
name of classes when transferring methods between object memories. Then<br>
textual class names are completely unconstrained, and you don't need<br>
class namespaces at all (or, effectively, every class has its own<br>
namespace). See [1] for details.<br>
<br>
> ...I must *strongly* urge the community to *please* pull down a Pharo<br>
> image, load up the Environments package, and give it a test drive...<br>
<div class="im">> I have to say that I thought the "language" used to express the<br>
> trappings of namespace in Environments were rather beautiful.<br>
<br>
</div> I cringed immediately, because it attempts to solve the problem of<br>
naming constraints by introducing additional constrained names (the<br>
names of the namespaces themselves).<br>
<br>
Also, we can solve the naming problem completely independently from<br>
how behavior is organized (packages, modules, etc.). I think we should.<br>
<br>
<br>
thanks,<br>
<br>
-C<br>
<br>
[1] <a href="http://netjam.org/spoon/naiad/#namespaces" target="_blank">http://netjam.org/spoon/naiad/#namespaces</a><br>
<font color="#888888"><br>
--<br>
Craig Latta<br>
<a href="http://www.netjam.org/resume" target="_blank">www.netjam.org/resume</a><br>
<a href="tel:%2B31%20%2006%202757%207177" value="+31627577177">+31 06 2757 7177</a><br>
<a href="tel:%2B%201%20415%20%20287%203547" value="+14152873547">+ 1 415 287 3547</a><br>
<br>
<br>
<br>
<br>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Casey Ransberger<br>
</div>