What you are suggesting sounds reasonable to me. So the point of the base TDMLDFDProcessor was to enable us to create a TDML processor from IBM DFDL (or other DFDL processors) for the IBM Cross Tester rig. It's supposed to be the minimal interface that will let our TDML runner drive a DFDL implementation.
If you want to create one class that implements both DFDLProcessor and TDMLDFDLProcessor that makes sense to me. Scala-wise, I'm not sure how it works if you inherit the same method signature from more than one trait, that is I'm not sure if you can implement it once and satisfy both traits. If that's a problem maybe DFDLProcesor needs to inherit from TDMLDFDLProcessor, so those signatures exist in exactly one trait? -mikeb On Mon, Feb 6, 2023 at 1:47 PM Interrante, John A (GE Research, US) < john.interra...@ge.com> wrote: > 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 > >
