FWD » Core Development » Base Language

To be able to use Java method calls for simple function calls (without IN SUPER or IN handle clauses), we need to emit worker methods for each function defined without IN SUPER or IN handle clauses:

function foo returns int:

end.

public integer foo()
{
    return fooWorker(false);
}
public integer fooWorker(boolean dynFlag)
{
    return integerFunction(..., dynFlag, new Block .... public void body {  bar(); } );
}

Attached are two testcases which demonstrate that the SOURCE-PROCEDURE must be set on the function call.

1. the conversion part, where the worker method is added
2. the runtime part, which involves the SOURCE-PROCEDURE mapping (and actually TARGET-PROCEDURE too)

Combine, I estimate 16 hours for it.

Thinking about this some more, I think we should be able to hide this completely in the runtime (no extra workers need to be emitted).

public integer bar() { ... }
public integer foo()
{
    return function(integer.class, ..., new Block .... public void body {  bar(); } );
}
...
ControlFlowOps.invokeFunction("foo");
foo();

How will ControlFlowOps.invokeFunction know to inform the integerFunction call (because until there we can't touch anything) that this call was "dynamic" and not "simple" ?

The key here is that before the body of the function foo can be called the BlockManager.functionBlock() will execute.

In the dynamic case, the ControlFlowOps.invokeFunction() can set a pendingDynFunc flag in BlockManager. This will be context-local and it can be checked (and cleared) at the top of BlockManager.functionBlock(). There is no user code that will ever execute in between the ControlFlowOps.invokeFunction() and the BlockManager.functionBlock(), so this is safe.

Of course, in the simple case, the flag is never set and normal rules apply.

With this in mind, the converted code is cleaner and we only need to change the runtime.

Attached update fixes the SOURCE and TARGET procedure push for java-style function calls. Built on top of the #1968 update.

More testing will be done at #2138.

See attached.

1116d.zip was bundled with #2138 work. Committed to bzr revision 10420.