A postscript version of this whole document is available here
The latex source is available here
The current system of implementing the call to asynchronous functions is fatally flawed and needs changing. An alternative is suggested.
The current system is that an extra argument is added to the end of the parameter list. There are two problems with this method:
In fact it seems that in general we cannot use the parameter list as a method of passing information about the way the function is called. We must find a different way to pass information to the object indicating that the call is to be asynchronous etc.
The best alternative is unclear. Some possibilities are:
ASYNCH(UCPPOBJECTPTR -> FunctionName(arguments))
This would allow the use of message system operators before and after the call, for example it might expand to:
MessageSubsystem -> SetNextCallAsynchronous(); UCPPOBJECTPTR -> FunctionName(arguments) MessageSubsystem -> SetSynchronous();
asynch(UCPPOBJECT) -> FunctionName(arguments)where asynch() is a function that takes a pointer to a UC++ object, sets a field in the object saying `next function along is asynchronous' and then returns the pointer.
UCPPOBJECT -> asynch() -> FunctionName(arguments)
CHECK THE PRECEDENCE ETC. RULES FOR THIS
UCPPOBJECTPTR ----> FunctionName(arguments)
This is perhaps obscure, but something like:
UCPPOBJECTPTR.asynch() --> FunctionName(arguments)
is quite nice. Problem with this method is that all pointers to UC++ objects then have to be smart pointers.
UCPPOBJECTPTR.CALLTYPE(asynchronous) --> FunctionName(arguments)
This would allow the passing of information about types of calls etc. at run-time. Might be other information we want to put in (e.g. ignore return type), result only useful if within X seconds etc.
Some of these schemes have simple extensions to deal also with operators.
ISSUES FOR DISCUSSION: there are several potential wrinkles with this scheme. Would need to be quite carefully designed.
In particular the method chosen has to be thread safe---the whole function call operation has to be atomic as we are setting modes.
A big issue waiting to be solved is that of return values from asynchronous function calls. When designing a method of signalling asynchronous calls we should think also about return values and build a scheme that encompasses them.
We should build a call mechanism that is clean enough for the end programmer to use, as we should deprecate the use of the (@ @) operator as it is an unnecessay extension of C++ syntax. If we get rid of it and activenew the user of a set of UC++-assisted libraries would not need to know anything about UC++.