// // ActionGroup -- collection of actions under partial order constraints // @deftype ActionGroup <ActionPlan, OrderedSet, CREATABLE> - createAction: anActionType; - createAction: anActionType : arg1; - createAction: anActionType : arg1 : arg2; - createAction: anActionType : arg1 : arg2 : arg3; - createActionCall: (func_t)fptr; - createActionCall: (func_t)fptr : arg1; - createActionCall: (func_t)fptr : arg1 : arg2; - createActionCall: (func_t)fptr : arg1 : arg2 : arg3; - createActionTo: target message: (SEL)aSel; - createActionTo: target message: (SEL)aSel : arg1; - createActionTo: target message: (SEL)aSel : arg1 : arg2; - createActionTo: target message: (SEL)aSel : arg1 : arg2 : arg3; - createActionForEach: target message: (SEL)aSel; - createActionForEach: target message: (SEL)aSel : arg1; - createActionForEach: target message: (SEL)aSel : arg1 : arg2; - createActionForEach: target message: (SEL)aSel : arg1 : arg2 : arg3; @end
@deftype ActionGroup <ActionPlan, OrderedSet, CREATABLE>An action group inherits its underlying representation from the OrderedSet type of the collections library. All the members of the ordered set must consist only of actions that are created by one of the createAction messages defined on ActionGroup itself. Once the actions are created, they may be accessed or traversed using standard messages of the OrderedSet type. Partial orders on these actions are also established by inherited messages. (.. Currently, partial orders are not implemented on either collections or action plans, but the messages inherited from OrderedSet will be the basic method for maintaining them once implemented.)
[createActionTo: aTurtle message: M(print)];M() is a macro defined in defobj.h which is just a convenient shorthand for the Objective C expression @selector(message-name). As in any selector, the message name must include all parts of the message including colons and subsequent argument portions. An example of a message with one additional argument is the following:
[createActionTo: aTurtle message: $m(move:) : (id)10];The createAction messages declare all arguments of the message to be of object id type, but you are free to cast other pointers and values up to the limits defined by the global portability assumptions. These is not portable across all machine architectures, but is expected to be portable across the 32-bit and 64-bit architectures on which Swarm will be supported. The message you send must still be declared to receive the type of argument you actually pass, before you cast it to the id type.
(.. Alternative approaches to argument typing are currently in development, but these will supplement rather than replace the current forms of createAction messages.)
The createActionCall: messages are similar to the createActionTo messages, except they specify the action to be performed as a binding of a C function to a list of argument values. The correct number of arguments for the function pointer passed as the initial argument must be supplied.
The createActionForEach: messages define a message to be sent in the same way as the createActionTo messages, but they assume that the object passed as the target argument is a collection object. They specify that each object available from that collection, using the standard messages of the Collection type in the collections library, is to receive the specified message.
The createAction: messages specify that processing of another action plan is to be performed by the action. The referenced action plan is performed in its entirety, from start to finish, as the effect of the single created action. If parameters are defined on the action plan, arguments for the action can also be given. (.. Currently this is not supported, so only the single argument form of createAction: should be used.)
Each of the createAction messages returns the action object which it creates. Each different kind of createAction message returns a different type of Action object with a matching name. These Action objects provide access to all the information with which the Action was initialized. The complete set of Action object types is defined below together with the messages that may be used to access their contents. (.. The implementation of the Action objects is currently undergoing change as the responsibility for parameter and return value typing gets taken over by ActionType in defobj.)
The action objects are an integral, controlled component of the action plan in which they are created. If they are removed from the action plan collection using a remove message, the only collection in which they may be reinserted is the same collection from which they came. It is permissible, however, to modify the base representation sequence by removing from one position and reinserting at another.
The contents of the action objects would ordinarily be referenced only by general-purpose tools to display or analyze an action plan structure. The action object id, however, can also be used to establish additional ordering constraints on any of the actions in a plan. These constraints supplement any initial order constraints established by the DefaultOrder option. Constraints may be established not only within the same plan, but between actions in different plans. (.. Partial order constraints are not yet implemented.)