Unnamed Grand Project Programmer's Guide

 

Introduction

 

Foo

 

Hands on: your first site

 

Create a package.

Add a namespace.

Create a Site class.

Add a drawOn: method.

Create a link to the site.

View the site.

Add an event handler for a mouse click.

Upgrade the site (and how to upgrade distributed objects in general)

View the site again with mouse clicks.

 

Programming in Smalltalk

 

(perhaps refer the reader to an existing book?)

 

UGP-specific tools

REPLServer, telnet.

alt-., getting a debugger.

Removing dominions.

Differences between UGP and the book referenced in the previous chapter.

Managing unhandled exceptions.

 

Packages and Namespaces

 

Introduction

 

In the original Smalltalk-80 system, all classes in a system were available from a global dictionary, the SystemDictionary which is also referable by the variable name "Smalltalk". This is retained in the Squeak Smalltalk system, where the action of loading ("filing in") code will modify existing classes. A loaded package in Squeak might add or modify methods from existing classes. Naming collisions are possible and have caused problems between two packages sharing the same name.

 

In a secure system where code might be loaded from a remote host, this is not a tenable configuration. To allow code to be loaded without affecting the running of the existing system, and to avoid naming collisions, a packaging and namespacing system has been developed with the following goals in mind:

 

• A loaded package does not affect the running of the rest of the system. Existing classes cannot be modified or redefined by a loaded package.
• Multiple versions of the same package can co-exist in the same system.
• Naming collisions are avoidable.
• Packages can be removed from the system as easily as they are loaded.

 

Design

 

In SecureSqueak, the Namespace class is a subclass of Dictionary. Namespaces map symbols to other namespaces, classes and global variables.

 

For example, there is a namespace called "Collections". It contains a mapping of #OrderedCollection to the class OrderedCollection. It also contains (XXX include an example of a sub-namespace). Code which is able to refer to the parent of the Collections namespace can then refer to Collections.OrderedCollection to refer to the class. If the code can refer directly to the Collections namespace, then the code can get a reference to the OrderedCollection class directly by the name "OrderedCollection".

 

A Package is the root of a group of related Namespaces. The Package class is a subclass of Namespace. The only place a class should reside is in a package. Objects are instantiated directly from classes inside a package. Packages are "live objects". In other environments, a package is a file which can be loaded; this is not the case in SecureSqueak. The primary place that a package lives is inside an image, with an option to file out a package to disk or send it across a network to another image.

 

Packages are referred to by a UUID. A UUID is a 128-bit unique identifier; see the UUID class for more information. A new version of a package could have a new UUID assigned to it, so that multiple versions of the same package can co-exist in the same image. Dependencies between packages are recorded using UUIDs such that the dependencies of a particular package are exact versions of other packages. This is an intentional design decision; the result is that a package, once loaded into an image with its dependencies, will run in exactly the same environment that it was designed, programmed and tested in. This moves the burden of finding package dependencies from the user to the developer. An automatic dependency downloading system will ensure that the system still remains easy to use.

 

Import Lists

 

Separation of Source and Bytecodes

 

A Package does not contain source code. A package contains namespace structure, class structure, global variables, methods and the bytecodes in those methods. The source code for a package is stored elsewhere; in the current version, it is stored in a PackageVersion class from which a Package can be compiled. The design decision behind this is that the source code management system can be easily updated or replaced in a live system, whereas the package, namespace and class format is much more difficult to modify as they are a core part of SecureSqueak with countless dependencies.

 

Version Control

 

As mentioned above, multiple versions of the same package can co-exist in the same image. Once a package has been developed and tested and is ready for public release, it should be "committed" as a particular version with its own UUID. Other packages can then be upgraded by the developer to have this newly released package as a dependency. (ech. Write this better TODO).

 

Troubleshooting

 

Check your import lists!

 

 

How code is managed in packages.

Namespace structure.

Import lists.

Using the tools; PackageManager, relinking, recompiling, etc.

Global variables

Version control.

Troubleshooting.

Division of source code and bytecodes.

 

Dominions

 

Resource control.

Granting access.

Running code in a different dominion.

When code runs out of resources.

Managing dominions.

Defensive Programming

 

(include defensing programming guide here)

Verifying a sender.

Interfaces (perhaps in its own chapter?)

Preventing subclasses.

Read-only objects.

 

Concurrent Programming

 

(refer user to The Little Book of Semaphores with quick explanation of how to do tricks in Smalltalk)

Future doing:

Concurrent Collections.

Scheduler details with Dominions.

Preparing for multi-cored Smalltalk.

 

Subcanvas

 

Graphics API.

Event API.

Drag and drop, cut+paste APIs.

Handling subcanvases.

Performance techniques.

Adding hyperlinks.

 

GUI Programming

 

How to use a basic widget set?

 

Services

 

Authenticating users.

Cryptographic routines.

(navigation api?)

Listing available services.

Adding new services (e.g. to toolbar).

Transactions, saving objects to disk.

 

Distributed Programming

 

(All about DPON)

(perhaps split this into several chapters?)

Object serialization.

Replication algorithms

Choosing a replication algorithm.

Writing a custom replication algorithm.

Existing replication algorithms.

How code is remotely loaded.

Capturing messages.

Referring to remote objects.

Sending messages.

Some basic algorithms.

Debugging distributed applications.

Broadcasting API.