UML22 — PrimitiveFunction

Reading the specification a PrimitiveFunction seems to be the equivalent of OpaqueExpression and OpaqueBehavior (once introduced, see issue 7335), but to be invoked by ApplyFunctionAction (i.e., some uninterpreted behavior defined by body and language). As issue 6625 correctly points out, it misses parameters. ApplyFunctionAction then imposes the additional constraint that the behavior it invokes does not access object memory or have side effects. So the first question to ask is what is the difference between OpaqueBehavior (once introduced) and PrimitiveFunction? They seem to be identical. Clearly there is duplication that should be eliminated. Of course, one could argue that one is a generic behavior and the other is a non-sideeffecting behavior, but in the current specification that is imposed by the invocation action, not by the behavior. So, assuming that we want this non-sideeffecting business, I see two strategies: Have just one kind of behavior, and two kinds of ways of invoking behavior (ignore a third kind, CallOperationAction as it does not have a bearing on this discussion): CallBehaviorAction and ApplyFunctionAction. Both would apply a behavior, but the latter have the constraint that the behavior will not have any side-effects. (ii) Have just one kind of behavior invocation, but two kinds of behavior: OpaqueBehavior and PrimitiveFunction, where the latter has no side effects. Of course, the difference between these two kinds of behaviors could just as easy be made by a Boolean flag (which would be preferable). I see no reason to rule out the use of PrimitiveFunction or a side-effect free behavior as a method. After all, a method need not have a side effect. There seems to be the additional constraint that the primitive function cannot access any object memory, so it would not be able to use the context object. However, to me that seems to be an unjustified constraint; what value does this constraint have? Note that option would not result in non-sideeffecting methods (not existing today). The minimal recommendation is to eliminate one of the superfluous metaclasss by using either or (ii) above. The preferred solution is to eliminate both PrimitiveFunction and ApplyFunctionAction as they are redundant. There is no clear need for the constraints imposed by this behavior.

see above