Sather logo

Introduction to Sather Libraries

Introduction

The concept of multiple libraries has been embodied into this implementation. In accordance with the concept of removing all of the classes but those necessary to define the language, the library classes used as a fundamental component of every day programming have been incorporated into the mandatory component of any implementation - known as the Required Library.

It is expected that most Sather distributions will include one or more of the following additional libraries which are expected to be self-contained except for necessary reliance on the Required Library -

Requirements

The process of defining a new library necessarily starts with a survey of the kinds of object whcih such a model needs to contain. Once a stable list is agreed upon then each object kind needs to be treated as an abstraction (not necessarily at this stage having anything to do with a Sather abstract class).

The features (behaviour) which an object kind is expected to have should then be individually listed and given a careful English (natural) language description. Once this has been done, these should be carefully gone through in order to ascertain that all features can be described in terms of other features - that no part of any description refers to a feature which has not been defined. This is the first step in ensuring that the definition of the abstraction is self-consistent!

Specification

Once the natural language description is complete then a formal specification (along the lines of the implicit specifications in the Sather language specification) needs to be produced. If at all possible this should be produced by someone other than the person who wrote the requirement!

Once the formal specification is written then a (preferably yet another) person needs to ensure that the requirement written in natural language and the specification written in some formal notation describe the same feature! At this stage it is vital that any feature referred to in the formal specification should appear in the abstraction. If they do not then the specification is not self-consistent - it is flawed!

Each abstraction in the library now has to be checked that nothing references functionality not contained in some other abstraction definition in the library. This is a most important library consistency check. It is necessary to ensure that any implementation does not use features other than those from the Required Library - when it comes down to writing code!

Abstract Classes

There is no hard and fast rule about whether an abstract class is essential or not. As a general rule an abstract class should be designed (using the formal specification detail to encapsulat concepts which may be common across a number of abstractions in the new library. If there is only ever going to be one implementation claass for some abstraction in the library then a suitably commented implementation class may be all that is needed.

Implementation Classes

It is usually a simple matter to decide which of the abstractions can be immutable classes or not. It is, however, not so easily determined if a reference class should have immutable semantics or not. Experience will usually dictate the suitability for immutable semantics - but this must, of course, be a decision made with efficiency considerations in mind - any large object with immutable semantics may well require much data copying in its implementation.

Testing

The most important part of building any library is to implement the testing design before implementing the library - from the original formal specification! Again, if at all possible, the designer and implementer of the tests and test harness should not be the person who implements the library - to avoid the test design reflecting how the library was implemented - rather than what the library does being tested!


Specification Index
Comments or enquiries should be made to Keith Hopper.
Page last modified: Tuesday, 17 October 2000.
Produced with Amaya