You may find ideas in <a href="http://wiki.squeak.org/squeak/5618">Naiad</a>, the module system for <a href="http://netjam.org/spoon/">Spoon</a>.<br><br><div class="gmail_quote">On Jan 20, 2008 11:30 AM, Jason Johnson <
<a href="mailto:jason.johnson.081@gmail.com">jason.johnson.081@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi all,
<br><br>Recently working in other high level languages I was thinking about<br>how modularity is accomplished in these systems and how we might do it<br>in Squeak.<br><br>Now we could of course simply add something trivial that formalizes
<br>the prefixes we are using now and hide them for us (sometimes), but<br>this doesn't really help our position much or make us much better at<br>"programming in the large".<br><br>Looking at other systems, Haskell, Ocaml and Lisp, it is interesting
<br>how they tackle this problem. What these systems all have in common<br>is a pretty simple idea: a module declaration defines what is<br>"exported" or visible from outside the module (or at least can be made
<br>so) and everything else is only visible to code inside the module.<br><br>So combining this simple concept with Smalltalk's unique "objects all<br>the way down" philosophy it occurred to me that a module could appear
<br>as simply a class like any other. The typical "import" mechanisms<br>could be ignored, and export is handled as it is now. That is, today<br>all classes and objects "export" methods; they simply respond to the
<br>ones they implement and DNU the ones they don't. Today, in Squeak all<br>classes are inserted into a global namespace and are therefor visible<br>from anywhere. With this module system I'm talking about, it would
<br>still work this way, but when one creates a new module, only the<br>"module class" would be inserted. Any classes inside the module would<br>not be inserted into the global namespace and would therefor not be
<br>visible globally.<br><br>The "module class" could chose to behave completely as a normal class,<br>i.e. the messages it exports/answers do their work by using the<br>module's internal classes and objects, as well as global classes and
<br>other modules. An example of this might be a Seaside application<br>which simply/responds to #renderOn: but internally has a complex<br>series of class/objects determine the behavior. From the point of<br>view of Seaside there is just one class that receives the render
<br>request. This is actually what we have right now, but the difference<br>is that today every class even remotely involved in the application is<br>visible everywhere, despite being essentially "private" to the
<br>application.<br><br>The "module class" could also chose to behave as a "namespace", simply<br>restricting access to its internal classes. But the most common<br>behavior would likely be a hybrid between these two possibilities.
<br>That is, often you would send a message to this visible "module class"<br>and it would behave as though it were a normal class. Other times you<br>might send a message and the return value would be an instance of one
<br>of the modules internal classes (think, a regular instance creation<br>method like Point>>x:y: that just happens to return an initialized<br>instance from a class inside the module).<br><br>Now, the question of course comes up of how such a system would look,
<br>be implemented, etc., etc. and I haven't really thought about that<br>part yet. I'm sure I'm not the first person to think of such a<br>system, so my question is: what systems do you all know about that<br>
sound like what I have described?<br><br>Thanks,<br><font color="#888888">Jason<br><br></font></blockquote></div><br>