What is an “object” within a computing or information system?

We use the term “object” here to summon connotations such as concreteness, individuality, discreetness and sometimes discreteness.
“Discrete” means having an existence of its own, apart from other things. “Discreet” means trustworthy as regards to keeping secrets.

Our objects lack mass, color and location, but they can be created, destroyed and traded as real objects.

Unlike most other computing entities, but like objects of the real world, objects cannot be copied or compared except under special circumstances.

A pocket calculator is an excellent example of a real world object which is like our Gnosis objects. It has internal states that are not immediately manifest {non-displayed storage}; it serves as a safe place to keep secrets {as long as you keep physical custody of the calculator}. It has internal rules of operation that may be proprietary and difficult to discern. It has external attributes that are intended to be useful and easy to understand. It can be used to compute as well as to store information.

We would be amazed if numbers entered into one calculator consistently appeared on the display of another calculator. If this happened we would no longer trust secrets to our calculator. If a box that appeared somewhat like the pocket calculator were advertised to transmit numbers we would not be amazed and we might find it useful.

We proposed to include such transmitting boxes in our term “object”. When we wish to exclude possibilities of transmission we refer to discreet objects. Such objects as our communicating calculators are said to be indiscreet.

A common notion in Gnosis is that a collection of code applies to many different cases but that the logic of the code is not responsible for distinguishing these cases. We speak of the code as defining an abstract data type and one of these cases as a value of that type. This manual uses the term “object” for the idea of a value of an abstract data type. Much of the design of Gnosis is to solve the problem of distinguishing these cases.

Consider the concept of an object and the data that represents the state of the object. We say that a system supports objects if the following rules are obeyed, whether enforced by programming discipline, compiler design or operating system structure.

The code that accesses the object representation is fixed and known to the system as a single unit and that code is the only code that accesses the object representation. Objects sharing the same code are said to be of the same type.

Any method of accessing the object is by some mechanism that we call here an “object name”. The object name effectively designates both the object representation and the unit of code that has sole access to that data. {An obvious general idea is to have a pointer to the code stored in the data.}

Some objects may not be shared. They have an internal state that is designed to serve the needs of some algorithm. A pocket calculator is such an object.

Some objects are designed to be shared by users for the purpose of cooperation among those users. A bulletin board {cork or electronic} is such an object.

Some objects may be used by users entirely independently of each other. Such objects should have no internal states between uses -- or at least no externally discernable states. We call such objects “immutable”. A compiler is such an object. There may be keys to immutable objects that can change them. In this case the object is immutable between invocations of such keys.

{arcane}See (p2,vo) for some related plans.

There is a technique that pervades and motivates the design of Gnosis. It has been called, among other things, “Data Abstraction”.

A collection of code that has been designed to work together has been produced under some design decisions. Such a collection is typically meant to be used as a component of a larger system. The designer of that larger system {called the “user” here} must be aware of some of the design decisions of the component. It has become increasingly clear in the last 10 years that this user must not be required to learn all of the design decisions of the component.

The design decisions that are required to be understood by the user of the code are called external specifications. The rest are called internal specifications. The venerable subroutine idea supports, but does not enforce, this separation. In Gnosis we enforce this separation to the point that the user of the code is unable to discern the nature of the internal specifications. If the algorithms therein are proprietary, they may thus be hidden from the user of the code. Later we go further and show how to hide the data that the code processes from the owner of the code.

There is a common mistrust of computers as a place to keep sensitive information. A widely held feeling is that a computer is one big box and someone who can get one piece of information from the box can get any other piece. It is nearly universally felt that someone who can introduce code into the computer can get any information there.

Many would trust a filing cabinet to which only certain trusted people held a key. They might also trust a computer with the same data if there were no wires from the computer except to terminals before the same people. These people are typically in contact with a larger set of second-rank people, these latter being less trusted. The people at the terminals are exercising some security policy. Note here that there need be no security policy programmed within the computer.

As the application grows we wish to replace the function of some of these people at the terminals with a computer programmed to communicate directly with some of the second-rank people. Some of the second-rank people will then have terminals but will be no more trusted than before. We must now program the security policy.

As the application grows yet more we will wish to hire more people to program than we wish to trust with all of the data of the institution. It is as if we now need to provide some of the second-rank people with the ability to introduce their own code for their own legitimate purposes. How do we give them access to the machine and yet limit their access?

{arcane}LOOSE END: Tie this in with objects!