<a href="http://gulik.pbwiki.com/Namespaces">http://gulik.pbwiki.com/Namespaces</a><br><br>There is code available on the 3.10 Package Universes that I'm currently using to varying degrees of success.<br><br>Gulik.<br>
<br><div class="gmail_quote">On Jan 23, 2008 6:36 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;">
So no one knows of a system like this? There's nothing new in our<br>field since decades so I'm sure there are papers or an implementation<br>out there, I just haven't found it yet.<br><br>On Jan 20, 2008 5:30 PM, Jason Johnson <
<a href="mailto:jason.johnson.081@gmail.com">jason.johnson.081@gmail.com</a>> wrote:<br>> 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>> Jason<br>><br><br></blockquote></div><br><br clear="all"><br>-- <br><a href="http://people.squeakfoundation.org/person/mikevdg">http://people.squeakfoundation.org/person/mikevdg
</a><br><a href="http://gulik.pbwiki.com/">http://gulik.pbwiki.com/</a>