Proposal for allowing the specification of object and function call attributes

Jonathan Poole

A postscript version of this whole document is available here

The latex source is available here

This proposal concerns a specification of the ability to specify attributes for classes, instances, functions and function calls. In the current model of UC++ the following attributes can be specified:

classes
there is only one class attribute: all UCPP classes are distributable. This attribute is implicit in them being UCPP classes. Can we imagine UCPP classes that are not distributable?

instances
these can have the following attributes

functions
all of these are implicitly callable either synchronously or asynchrously, with the default being synchronous and the choice being made at the point of function call

function call
there is one attribute, whether the function is called synchronous or asynchronously, with the default being synchronous (or non-blocking, to use a better term for it)

Here we look at what attributes might be wanted, and how we would state them in a program and how we can implement defaults.

What Attributes are Wanted?

There are two types of attributes: object attributes (stated at the class or instance leval) and function attributes (stated at the function or function call level). We look at these two categorites separately below:

Object Attributes

These may be set as defaults at the class level (and inherited from base classes, including defaults from UCPP), and overridden at the instance level, using parameters to the new(attributes) call, or set dynamically.

Possible attributes:

activity
whether active or passive

location
on which architecture, machine etc the object resides

selectivity of available methods
we might want to be able to state that only certain services are available at particular time (can presumably be handled using usual C++) or that according to the stat of the object different methods are selected (is this necessary---again could be done using switch statement). See paper on QPC++ project for more details.

body-function?
in QPC++ there is a `body` function optionally defined for each class, which is a function that is run by the object after initilization. Is this any advatage---presumably this can be kicked off anyway bycalling a function asynchronously. But, it would save a message, and put the structure into the object rather than the caller. Generally seems non-useful.

persistance

executable

exception handling
for example how failure should be signalled to other objects.

fault tolerance
may be able to do certain fault tolerant things (e.g. replication) for a certain overhead.

default function behaviours
setting default attributes for function calls as detailed below

CORBA compilance?
we might want to be able to state that certain objects comply to some other form to allow them to interface to other object managment systems

trace parameters
?

Function Call Attributes

Each function call with have certain behaviour, some of which is stated in standard C++ (e.g. the code, return type, parameters). Other attributes that become relevant in a distributed model are as discussed below. These might be stated in the function itself or as part of the function call.

whether blocking
a particular function might state whether it is blocking or non-blocking and whether this can be overridden at function call time.

bufferable
a bufferable function call is one where a series of calls to the same function (or perhaps different functions) can all be packaged together and sent at once, to save network overhead. This might be appropriate for sending messages to an object that is undertaking a secondary task. At a certain point this buffer will have to be flushed (perhaps if the object gets to a wait state, or if a non-bufferable function is called).

priority
some messages (control messages) might have higher priority and should therefore be processed in advance of other messages.

expires
some messages might expire after a certain time or if certain conditions arise.

Stating Attributes

In this section we look at how attributes might be stated by the programmer, and how defaults can be handled.

Class Attributes

We need to stick a directive into the definition of the class.

Instance Attributes

These are stated as part of the new(attributes) statement at instance creation time.

It might be that we want to change attributes after creation time. Who could change these---only the object itself perhaps? Or the creator? In the short term it does not seem that we would want to change these at all.

Function attributes

These would be stated inside the body of the function (before the redirector macro



Jonathan Poole
Wed Aug 2 17:54:40 BST 1995