<br><br><div><span class="gmail_quote">On 9/19/07, <b class="gmail_sendername">Chris Muller</b> <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> > I agree we need namespaces, I just think we can do better,<br>><br>> That's the thing, not everyone agrees about needing them, which in the past<br>> has made adding them a losing battle.<br><br>+1, and Göran's proposal is transparent and preserves the classic
<br>simplicity and dynamism of Smalltalk.<br><br>Squeak offers the possibility that "power users" (not hard-core<br>developers), someday, maybe after Squeak By Example showing them how,<br>will "hop in and drive" to sketch a program. But as soon as we
<br>require import declarations, etc. just to sling a simple program<br>together, then you've lost the "power users" group and catering<br>exclusively to just programmers and engineers. Not to mention, it<br>
feels a bit early bound.<br><br>Future Squeaks are moving toward smaller images with less code, where<br>name collisions will be virtually non-existent. In each of these tiny<br>images, will we have a big honkin' namespace system "just in case?"
<br>Even in todays phat images, name collisions are the 1% case, so the<br>solution should have the benefit of being invisible 99% of the time,<br>and handling the problem as simply and elegantly as possible that 1%<br>of the time. Göran's approach seems to do this.
</blockquote><div><br><br>Naming collisions aren't my concern.<br><br>I want to be able to load untrusted code and run it, securely.<br><br>This means that I need a unit for loading remote code, thus the package was born. It also means I need to have complete control over what that remote code has access to. If you give untrusted code access to the global SystemDictionary, it has access to everything (which I consider bad practice). To solve this, I've been working on a design for Namespaces that lets a code loader show a certain amount of discretion about what a package has access to (
i.e. the import lists).<br><br>Answering your points directly, I'm hoping that my tools will not be that difficult to use so that even power users can use them. The import lists should usually be automatically populated by the NamespaceBrowser.
<br><br>As with smaller images, naming collisions only require two loaded packages to happen (even on the smallest image), and I'd find it pretty damn annoying if they happen for 1% of all class names. That's every third or fourth package.
<br><br>Gulik.<br></div></div>