Implementation details must be added to the ``Impl'' files generated in Subsection 10.4.1. Changes to these files must be made between code splicer pairs to ensure their retention in subsequent invocations of Babel. Code splicing is a technique for preserving hand-edited code between multiple invocations of Babel. This allows a developer to refine the implementation without losing previous implementation details. Hence, code between splicer pairs will be retained by subsequent invocations of Babel; whereas, code outside splicer pairs will not.
Another interesting fact of the implementation-side is that it inherits from
the client-side Java class. This allows calls to local methods
directly. Take this recursive Fibonacci function implementation, for example
class Fib_Impl extends Fib { public int getFib_Impl(int x) { // DO-NOT-DELETE splicer.begin(ExceptionTest.Fib.getFib) if(x >= 2) { return getFib(x-1) + getFib(x-2); } else { return 1; } // DO-NOT-DELETE splicer.end(ExceptionTest.Fib.getFib) } }
The client-side class name is Fib and, therefore, the implementation-side class is Fib_Impl. The same relation holds for the getFib method. Note that getFib, the client-side method, can be called directly. A call like this goes through Babel glue code, as it should. That is, calls directly to _Impl methods should never be made since they break the object model for the current class and will not work on different objects. The reason for this situation is that, by making local calls, within fib_Impl for example, any inheritance information stored in the middleware is lost. It also means implementation-side object inheritance from non-SIDL Java classes is impossible. In fact, since no splicer blocks are available for inheritance, implementing interfaces on the implementation-side is also not supported since having the implementation-side inherit from non-SIDL classes is probably not a good idea.