Hi all.<br><br>I&#39;m currently implementing hierarchical Namespaces for Squeak, which I need for another project of mine. The current design is as follows:<br><br>- Each Namespace is a Dictionary mapping #names to &quot;global&quot; variables, classes, and sub-Namespaces.
<br>- Each Namespace has a list of imports, which is a list of other Namespaces that are searched when a global variable name is used.<br><br>Source code here: <a href="http://www.squeaksource.com/SecureSqueak">http://www.squeaksource.com/SecureSqueak
</a>.<br><br>So when writing code, your class resides in a particular Namespace, and if you refer to a global variable, it is searched for in that Namespace followed by that Namespace&#39;s import list.<br><br>Currently, I&#39;ve got the basic Namespace structure working, and I&#39;ve been making a special browser, based on the PlusTools browser that uses ToolBuilder, that lets you browse a Namespace hierarchy and manage import lists.
<br><br>Now, the question: How can I get Namespaces out of an image? I&#39;ve had the following ideas, and I&#39;d like people&#39;s comments:<br><br>- Namespace source code could be stored in squeak.sources, and filed out as they are now but with a few changes to class definitions.
<br><br>Advantages: Most tools in Squeak would probably still work.<br>Disadvantages: Not backwards compatible, tools will need modifying a bit.<br><br>- Namespace source code, rather than being stored in squeak.sources, could be stored in a hierarchy of directories under individual files for each class, with version history stored in or alongside those files.
<br><br>Advantages: You can use Subversion / CVS with this approach, or in the worst case, use a text editor.<br>Disadvantages: ...<br><br>- Namespace source code could be kept only in the image. Source code would be a Text object.
<br><br>Advantages: You get to keep formatting info.<br>Disadvantages: If the image breaks, so does your source code.<br><br>Keeping source code in the image would mean that some mechanism of importing or exporting a Namespace tree would be needed. I&#39;ve thought about&nbsp; modifying Monticello. Currently, .mcz packages contain a snapshot/source.st which could be replaced with a directory tree of source code.
<br><br>Thoughts? Can we live without changesets if you had good Monticello support? Can squeak.sources be ditched, instead storing source code in the image?<br><br>Michael.<br>