Managing Packages 

Packages are used as a way of managing code. Compiled code is transferred between images in packages.

For End Users

Packages are distributed in binary form only. They contain no source code. Some other mechanism (such as PackageVersion, PackageRepository, described below) is used for managing the source code.

Package is a subclass of Namespace, and forms the root of a namespace hierarchy of related classes. See Namespaces for more info.

Each Package is a snapshot of code at a particular time. If (compiled) code in a package is modified, a new Package is made with those modifications and the original package remains unmodified.

Packages can be read-only or writable. Typically an end-user would only be interested in read-only packages. A developer would use writable packages.

Packages contain classes that are used directly. If no instances of any of those classes exist, then that Package simply gets garbage collected like any other object. In other words, there is no reason to uninstall Packages. Packages are also intended to be loaded automatically; if a user somehow gets an instance of a particular object, the Package that contains the implementation of that object would also be somehow automatically loaded.

For Developers

An instance of Package does not contain source code. Source code is managed using other mechanisms. One mechanism which is being developed by me uses PackageVersions and PackageRepositories and a PackageManager.

Alternative mechanisms for managing source code should also be possible.

A PackageManager contains a list of PackageRepositorys. The PackageManager is the starting point for editing code; it allows the programmer to edit, add and remove PackageRepositorys. It is also referred to by the NamespaceBrowser (the main code browser) when searching for particular Classes or Namespaces.

A PackageRepository is a sequence of versions of a particular Package, known as PackageVersions. The versions are the historical versions of that package, with the latest version (the "head" in Subversion or CVS) being the package that the developer would typically be interested in. These versions are all read-only. To make changes to a PackageVersion, a "working copy" must first be made, which is a writable package.

(In the current implementation, the "read-only" attribute is only symbolic because it has not yet been implemented. It relies on the developer's honesty in not editing packages marked as "read-only")

A PackageVersion contains the source code for a particular version of a Package. It can be compiled to produce a Package object which can be loaded and run.

(In the current implementation, the old method of storing source code using .sources and .changes files is still being used, so the classes themselves still 'store' source code. This will change at some point in the future.)

(In the current implementation, there is poor support for getting PackageRepositories in and out of an image. It is possible to file out a Package, but there is still no support for filing out a PackageVersion or whole PackageRepository. This will be implemented at some time.)

Editing code

To edit code, the developer would first obtain a PackageRepository using whatever means. It is intended that these repositories will be distributed objects of some sort, as well as having support for filing in and out entire repositories.

The developer would then create a working copy (a writable PackageVersion) and make changes by using the NamespaceBrowser. As the user makes changes, the binary Package associated with that PackageVersion is also updated with those changes so that the developer can test them immediately.

When finished, the user would "check in" changes back to the repository. This involves converting the "working copy" into a read-only PackageVersion, which gets added to the PackageRepository's history. This becomes the new "latest version".

Other repository commands such as merging code, branching (i.e. making a copy of the PackageRepository), viewing differences between PackageVersions, exporting code and so forth will eventually be implemented.

Package dependencies

Packages contain a number of nested Namespaces. Each Namespace has an "import list", which is a list of other Namespaces from various Packages; this import list is referred to when the developer uses a class name or global variable in his/her code.

The import list refers directly to Namespace instances. As a result, an import list entry refers to an exact version of a Namespace in an exact version of a Package. If code is transferred from one image to another, every single dependent Package must also be loaded in the remote image. This has the desirable effect of ensuring that code runs in exactly the same environment (except for global variable state) that the developer originally wrote and tested it in. It also guards against "bit-rot".

As a result, when editing a working copy, the developer must update the import lists of the places where that package is referred to and make sure the import lists refer to the working copy. Otherwise, the changes will not affect and have no effect on the system. The tools should have a feature that upgrades a package to make sure it uses all of the latest versions of each dependency that is available.

Namespace import lists are described in more detail in the Namespaces page.

Programming with Packages

Potential problems:

Because you can have multiple versions of the same Package, you will have multiple classes with the same name and more or less the same implementation.

How do you compare the classes of two objects? How is >>isKindOf: and >>isMemberOf: implemented?

Should interfaces (aka Java interfaces) be implemented?

How do you upgrade objects to newer versions of their class?

Upgrading objects: an instance of the new class needs to be made. The data will need to be copied from the old class to the new class. >>copyFrom: and >>deepCopyFrom:?  (TODO: what is available in the ANSI spec?).

To avoid the problem of comparing classes (i.e. self assert: [ bob isKindOf: aClass ]), interfaces could be made and objects could be tested to see whether they comply with a particular interface. Class compliance to an interface can be cached to improve performance.