Ever since object-orientation was introduced in programming languages there have been efforts in transforming programs built up from functions into object-oriented programs. All these efforts have in common that they lack explicit descriptions and computational models for functions and objects.

In our view the execution of a function can be seen as the execution of an object. It is first instantiated from its definition, then executed, and then destroyed. Here, the instantiation and destruction are implicit, in contrast with the execution of an object where these are explicit. With a function, there is no control over its lifetime. An object has a state, and this state can be manipulated by invoking methods of the object (making requests to the object). This state is implicit with the object and exists only during the lifetime of the object. During several executions of a function a state can be preserved by explicitly storing it in memory.

The execution of a program built up from functions can be seen as the execution of an object. The functions are the methods of the object, and all the variables as the state of the object. A variable actually is itself an object. It is instantiated, manipulated by invoking certain operations on it, and destroyed.

We conclude that the program, its functions, and its variables are all objects. The methods of an object are in essence functions and are thus objects too. The state of an object can be seen as the variables of that object and are thus objects as well. So in essence there is not much difference between elements of function-oriented and object-oriented programs. The differences are determined by the computational models for them.

We described a framework of computational models that allow for the concurrent execution of functions. We extended this framework with communication between functions. We applied this framework to object execution, resulting in a framework of computational models that allow for the concurrent execution of objects. The sequential execution of functions and objects is just a possible implementation of an abstract computational model that allows for concurrent execution. All this clearly supports our conclusion that everything can be considered an object.

Although everything can be considered an object, this does not mean we can considered it complying with the object-orientation paradigm. For this it has to fulfil the fundamentals of object-orientation. There we defined a model for object-orientation with as much abstraction as possible so that it can be applied in several phases of software development.

We show that, through the abstractions we have made to establish the framework of computational models, we comply with the fundamentals of object-orientation.

Objects

The framework of computational models for function execution and object execution showed that, by abstracting from the ways of scheduling, functions can be considered objects. However, in order to make a shift to the paradigm of object-orientation these objects must have some characteristics as well. First they have to have to an identity by which they are known to other objects. Instances of functions are known by their identity obtained on creation of the instance. This identity can be passed on to other instances of functions. Secondly, they have to have a state, although this state may be empty. The instance of a function can keep a state with the use of local variables. It is also possible that an instance of another function is used to keep a state. And thirdly, they must have an observable behaviour. Their behaviour is observable by the effects they have on their environment based on their state and the relations with other objects. With these three characteristic an instance of a function can be considered an object in the modelling paradigm of object-orientation.

Relations

We described communication mechanisms for concurrent functions that solve the problems inherent with concurrency when communicating through shared memory. These mechanisms are functions themselves and thus objects. By restricting communication only through these mechanisms, objects can only interact with each other by passing messages. The passing of messages between objects describes the relations between the objects.

Abstraction

The behaviour of a group of objects that is related to objects outside of the group only through one of its members can be observed as the behaviour of that one object. What is going on inside this group is not observable to objects outside of this group. Because of this, the internal behaviour of this group can be abstracted from. So, by restricting communications between instances of functions through the mechanisms that are instances of functions themselves, it is possible to hide the implementation of its behaviour and the recording of its state.