Proposal for allowing the specification of object and function
A postscript version of this whole document is available
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:
- 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?
- these can have the following attributes
- active or passive
- if active then location
- 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.
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
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
- whether active or passive
- 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.
- 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.
- 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
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.
- 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).
- some messages (control messages) might have higher
priority and should therefore be processed in advance of other
- some messages might expire after a certain time or if
certain conditions arise.
In this section we look at how attributes might be stated by the
programmer, and how defaults can be handled.
We need to stick a directive into the definition of the class.
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.
These would be stated inside the body of the function (before the
Wed Aug 2 17:54:40 BST 1995