Semantic Files

Conventional file systems often provide a simple procedural interface with routines for example to insert or delete a record for a particular file. In this sense they can be viewed as providing a very minimal support for the information hiding principle, which at least hides details such as the physical location of the file on disc but may also provide a basic structuring and accessing mechanism (e.g. indexed sequential).

The alternative provided by Timor allows a much more flexible approach to information hiding, with corresponding software engineering and protection benefits. Consider for example a bank accounts file in a conventional environment. The file system will provide operations that allow individual accounts to be inserted, viewed, modified, deleted, etc. But these take no account of the fact that the records are bank account records. From the viewpoint of the file system they could just as easily be car registration records, or club membership records, etc.

This means that the entire semantics associated with the information in the file must be programmed in the programs which use the file. But this leads to the same disadvantages which led Parnas to propose the information hiding principle. Each program using the file – and in a banking system that will be a large number, e.g. a program for managers, one for tellers, one for accountants, one for calculating interest, etc. – must know the layout of an account record and the significance of its fields. So, changing something about the record layout will probably involve changing several programs. It also leads to duplicated software in the individual programs, where they have to provide the same or similar functionality.

In Timor all of this can easily be avoided by providing a semantically appropriate interface to the information hiding file, e.g. a method for adding interest to an account, one to authorise an overdraft, etc. This has all the advantages of information hiding mentioned earlier.