<br><br><div><span class="gmail_quote">On 11/30/06, <b class="gmail_sendername">Göran Krampe</b> <<a href="mailto:goran@krampe.se">goran@krampe.se</a>> wrote:</span><div> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
But others<br>might benefit from at least *contemplating* that namespaces:<br><br>- Don't *have* to be hierarchical.</blockquote><div><br>Well, this is just the next step in the evolution of namespaces. How long would it take before you go from:
<br><br>Morphic::StringMorph<br><br>to <br><br>Morphic::Base::StringMorph<br><br>or<br><br>Squeak::Morphic::StringMorph<br>Croquet::Morphic::StringMorph<br>Tweak::MorphicCompatibility::StringMorph<br><br>or even<br><br>Squeak::Base::Graphics::Morphic::BasicMorphs::Text::StringMorph
<br>(as opposed to any of the other 114 StringMorphs in a distributed Squeak environment...)<br><br>Arguably, we're not at that stage yet, and one-level Namespaces fix all our current problems. I've already been bitten by lack of Namespaces - I couldn't implement my own SocketStream because the name was already used.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">- Don't *have* to use file/class/package level imports.<br></blockquote></div>
<br><br>Like I mentioned earlier, I need this feature for securities' sake, but I'm probably going to implement a completely different Namespace system for my own use.<br><br>I'm quite impartial to how Namespaces are implemented in Squeak and I think your proposal is fine, provided that I can remove it later if it gets in my way. Currently this seems trivial, and if people don't start making unnecessary prolific use of the new Namespace syntax then I could still re-use most of the existing code.
<br><br>So.. +1 to your proposal from me.<br><br>Michael.<br>