I want to merge Runtime2DataProcessor.scala into Runtime2TDMLDFDLProcessor.scala since doing so will reduce codegen-c's number of lines of code and number of classes. My experience writing a TDMLDFDProcessor for another code generator (not released yet) and writing unit tests for it has shown me that the Runtime2TDMLDFDLProcessor and Runtime2DataProcessor are the same from a caller's point of view. Either way, the caller has to call compileCode, get the executable file's path, call "new Runtime2TDMLDFDLProcessor(executable)" or "new Runtime2DataProcessor(executable)" to get a processor object, and then call its parse method with arguments. The parse result object is the same too, just wrapped in a TDMLParseResult class if it comes from Runtime2TDMLDFDLProcessor.
I assert that both unit tests and the TDML Runner are the only pieces of Java/Scala software that will ever generate code from a DFDL schema, build an executable, call that executable, and return a parse result. I can type "daffodil generate c -s <schema>" commands and use the C code without involving any other Java/Scala code. I can type or script "make -C c" and "c/daffodil parse -o out in" commands for more automation too. I also can type "daffodil test -I daffodilC <tdml>" commands or run TestXXX.scala classes which call a Runner object, which are the only times I've ever needed to run the C executable from Java/Scala. I'd like to dispense with two such similar APIs. Instead of wrapping the TDML API around the Processor API, I'd like to implement the TDML API directly with no underlying Processor API needed. I assert that code generators don't need to provide a processor object API (no need to implement a getProcessor() method and a DataProcessor API). Code generators only need to provide a TDMLDFDLProcessorFactory for the TDML Runner to use. If any new future Java/Scala callers do come along, they can call "new Runtime2TDMLDFDLProcessor(executable)" to get a processor object with the same functionality as "new Runtime2DataProcessor(executable)" anyway. Any thoughts about or objections to merging Runtime2DataProcessor.scala into Runtime2TDMLDFDLProcessor.scala? I will merge the classes in a separate PR from a PR renaming daffodil-runtime2 to daffodil-codegen-c to make reviewing each PR easier. John
