Namespaces for distributed environments.
Posted 24 Nov 2006 by mikevdgOne of the requirements of DPON (a distributed Smalltalk environment) are Namespaces. Namespaces and the Smalltalk SystemDictionary aren't needed per se, but provide a useful means of referring to a Class object by name.
Namespaces are a construct useful only to programmers. The Smalltalk SystemDictionary can be thought of as a flat namespace, mapping class names to Classes in the local image. A Class does not need to belong to any Namespace in order for it to be functional, but belonging in a Namespace makes that class easier for programmers to work with.
Firstly, there is the issue of recompilation. If a class is modified and if a method contains a named literal (such as the name of another Class), then that method would need to find a reference for that named literal somehow. This is the first useful purpose of a Namespace.
Secondly, namespaces can include some mapping mechanism, such as a tree structure of namespaces and sub-namespaces in order to prevent namespace collisions. This allows the programmer to be more concise about what he means when he says "Field" - is that "Database::Field" or "FootballGame::Field"?
Thirdly, namespaces provide a good grouping mechanism. It is then possible to search something in a Namespace of Classes rather than the entire Smalltalk image. It also allows a Namespace to be saved to disk or sent across the network as a general package of Classes.
Currently, DPON refers to a remote Class using a (namespace reference, class name) tuple. It assumes that an entire Namespace of classes will be brought over the network in one go and instantiated locally. My belief is that this will be a suitable level of granularity to load remote code, rather than loading each class individually.
By having Classes distributed across the network on a Namespace-by-Namespace basis, it is possible to implement different replication behaviours for each individual Namespace. Two Namespaces need not be of the same Class (and in DPON, replicative behaviour is done on a Class by Class basis) so that it is possible for multiple implementations of Namespaces to exist. An example of this would be a developer's release of a Namespace (i.e. a package of software) compared to a stable release of a Namespace. The developer's release would want to update all it's classes across the network as soon as they change, whereas the stable release can be considered an immutable Namespace.
Michael.
Code for this, posted 19 Dec 2006 by mikevdg
Code for this is available from My SecureSqueak project on http://www.squeaksource.com/. Currently it's still being developed.The current design is that each Namespace is a Dictionary subclass mapping #Names to sub-namespaces, classes and/or shared variables. There's also a pointer in each Namespace which points to the root Namespace in the hierarchy, and a list of "imports" which are valid only for classes in that particular Namespace object.
This allows, for example, either:
o := Kernel.Object new. "If the import list does not include the Kernel namespace"
or
o := Object new. "If the import list has included the Kernel namespace".
This allows many interesting things to happen. Firstly, it is possible to use this as a security mechanism to prevent a class having access to other classes. Secondly, it allows multiple versions of the same "package" to exist on an Image - for example, an old and a new version of Morphic could co-exist in an image.
[ Home | Articles | Login/Account | People | Projects ]