Namespaces project for Summer of Code 2007
Last updated at 4:15 am UTC on 16 March 2007
James Foster (Google Account: WeybridgeWay)
Produce a namespace implementation for Squeak.
This will involve:
- Identify existing namespace approaches in other Smalltalk dialects (GemStone, VisualWorks, GNU Smalltalk etc.)
- Identify existing namespace proposals for Squeak
- Design/implement namespace for Squeak
- Add tool support for selected implementation
Traditionally, all globals in Smalltalk are visible to all code in the image. While this works fine on a small scale, it becomes a problem when code originates from many different individuals or teams (which is particularly common in an open source community such as Squeak). Each module that is developed will naturally have class names that reflect the domain being modeled. In any large system there is likely to be overlap among the names chosen (e.g., Person, User, Preferences, Server, Client, etc.). The typical approach is to preface class names with an abbreviation of the module name. While this works, it is cumbersome and tends to make names either cryptic or cumbersome. What is needed is a system in which internal class names (and other "globals") are visible only to the internals of a module that defines them. Each module should be able to reference its own names without exposing other modules to anything more than a public API.
An additional challenge is that multiple modules might add the same method to base classes–sometimes with conflicting implementations. This again presents a challenge to coordination among various contributors to a large system (particularly with an open source system where the contributors are not under some central direction). What is needed is an approach in which two or more modules can define the same methods, yet be protected from overlap.
Benefits to the Student
Exposure to compiler and tool building.
Benefits to the Community
A much richer environment that allows more sharing of code without the risk of overlap.